Date   

Re: [sfc-dev] [release] New project build cycle between sfc and ovsdb?

Reinaldo Penno <rapenno@...>
 

Yes. 

From: Colin Dixon <colin@...>
Date: Friday, June 26, 2015 at 9:39 AM
To: Thanh Ha <thanh.ha@...>
Cc: "sfc-dev@..." <sfc-dev@...>, "<ovsdb-dev@...>" <ovsdb-dev@...>, "release@..." <release@...>
Subject: Re: [sfc-dev] [release] New project build cycle between sfc and ovsdb?

In that case, can we remove the ovs-sfc directory from the ovsdb project if it's really dead code?

--Colin


On Fri, Jun 26, 2015 at 5:04 AM, Thanh Ha <thanh.ha@...> wrote:
Ok maybe false alarm. I did a recheck on ovsdb and it was successful despite the the dependencies.log reporting that ovsdb needed sfc. I guess I'm not blocked on this as I had thought.

Thanh

On 26 June 2015 at 04:38, Brady Allen Johnson <brady.allen.johnson@...> wrote:

SFC definitely uses OVSDB, but I cant imagine why OVSDB would need anything from SFC.

OVSDB used to have some implementation code for SFC, but that should have been removed long ago.

Regards,

Brady



On 06/26/2015 10:34 AM, Thanh Ha wrote:
Hi Everyone,

Just trying to figure out how to solve this build cycle. It seems sfc needs ovsdb and vice-versa causing a build cycle between the 2 projects (see below). How do we resolve this? and is there a way we can re-organize these repos so that this doesn't happen in the future?

Regards,

Thanh

% find . -name pom.xml | xargs grep sfc
./commons/parent/pom.xml:    <ovsdb.ovssfc.version>0.1.1-SNAPSHOT</ovsdb.ovssfc.version>
./commons/parent/pom.xml:              **/openstack/,**/ovs-sfc/,
./features/ovs-sfc/pom.xml:  <artifactId>features-ovs-sfc</artifactId>
./features/pom.xml:    <module>ovs-sfc</module>
./ovs-sfc/pom.xml:  <artifactId>ovssfc</artifactId>
./ovs-sfc/pom.xml:      <groupId>org.opendaylight.sfc</groupId>
./ovs-sfc/pom.xml:      <artifactId>sfc-model</artifactId>
./ovs-sfc/pom.xml:              /OSGI-OPT/ovs-sfc/53-ovssfc-provider.xml=${project.basedir}/src/main/resources/initial/53-ovssfc-provider.xml,{maven-resources}


% find . -name pom.xml | xargs grep ovsdb
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:        <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./sfc-karaf/pom.xml:        <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-model/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-model/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:           <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:           <version>${ovsdb.southbound.version}</version>
./sfc-sb-rest/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-netconf/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./pom.xml:        <ovsdb.southbound.version>1.1.1-SNAPSHOT</ovsdb.southbound.version>



_______________________________________________
release mailing list
release@...https://lists.opendaylight.org/mailman/listinfo/release



_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release


_______________________________________________ sfc-dev mailing list sfc-dev@... https://lists.opendaylight.org/mailman/listinfo/sfc-dev


Re: [release] New project build cycle between sfc and ovsdb?

Colin Dixon <colin@...>
 

In that case, can we remove the ovs-sfc directory from the ovsdb project if it's really dead code?

--Colin


On Fri, Jun 26, 2015 at 5:04 AM, Thanh Ha <thanh.ha@...> wrote:
Ok maybe false alarm. I did a recheck on ovsdb and it was successful despite the the dependencies.log reporting that ovsdb needed sfc. I guess I'm not blocked on this as I had thought.

Thanh

On 26 June 2015 at 04:38, Brady Allen Johnson <brady.allen.johnson@...> wrote:

SFC definitely uses OVSDB, but I cant imagine why OVSDB would need anything from SFC.

OVSDB used to have some implementation code for SFC, but that should have been removed long ago.

Regards,

Brady



On 06/26/2015 10:34 AM, Thanh Ha wrote:
Hi Everyone,

Just trying to figure out how to solve this build cycle. It seems sfc needs ovsdb and vice-versa causing a build cycle between the 2 projects (see below). How do we resolve this? and is there a way we can re-organize these repos so that this doesn't happen in the future?

Regards,

Thanh

% find . -name pom.xml | xargs grep sfc
./commons/parent/pom.xml:    <ovsdb.ovssfc.version>0.1.1-SNAPSHOT</ovsdb.ovssfc.version>
./commons/parent/pom.xml:              **/openstack/,**/ovs-sfc/,
./features/ovs-sfc/pom.xml:  <artifactId>features-ovs-sfc</artifactId>
./features/pom.xml:    <module>ovs-sfc</module>
./ovs-sfc/pom.xml:  <artifactId>ovssfc</artifactId>
./ovs-sfc/pom.xml:      <groupId>org.opendaylight.sfc</groupId>
./ovs-sfc/pom.xml:      <artifactId>sfc-model</artifactId>
./ovs-sfc/pom.xml:              /OSGI-OPT/ovs-sfc/53-ovssfc-provider.xml=${project.basedir}/src/main/resources/initial/53-ovssfc-provider.xml,{maven-resources}


% find . -name pom.xml | xargs grep ovsdb
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:        <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./sfc-karaf/pom.xml:        <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-model/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-model/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:           <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:           <version>${ovsdb.southbound.version}</version>
./sfc-sb-rest/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-netconf/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./pom.xml:        <ovsdb.southbound.version>1.1.1-SNAPSHOT</ovsdb.southbound.version>



_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release



_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release



Re: [release] New project build cycle between sfc and ovsdb?

Thanh Ha <thanh.ha@...>
 

Ok maybe false alarm. I did a recheck on ovsdb and it was successful despite the the dependencies.log reporting that ovsdb needed sfc. I guess I'm not blocked on this as I had thought.

Thanh

On 26 June 2015 at 04:38, Brady Allen Johnson <brady.allen.johnson@...> wrote:

SFC definitely uses OVSDB, but I cant imagine why OVSDB would need anything from SFC.

OVSDB used to have some implementation code for SFC, but that should have been removed long ago.

Regards,

Brady



On 06/26/2015 10:34 AM, Thanh Ha wrote:
Hi Everyone,

Just trying to figure out how to solve this build cycle. It seems sfc needs ovsdb and vice-versa causing a build cycle between the 2 projects (see below). How do we resolve this? and is there a way we can re-organize these repos so that this doesn't happen in the future?

Regards,

Thanh

% find . -name pom.xml | xargs grep sfc
./commons/parent/pom.xml:    <ovsdb.ovssfc.version>0.1.1-SNAPSHOT</ovsdb.ovssfc.version>
./commons/parent/pom.xml:              **/openstack/,**/ovs-sfc/,
./features/ovs-sfc/pom.xml:  <artifactId>features-ovs-sfc</artifactId>
./features/pom.xml:    <module>ovs-sfc</module>
./ovs-sfc/pom.xml:  <artifactId>ovssfc</artifactId>
./ovs-sfc/pom.xml:      <groupId>org.opendaylight.sfc</groupId>
./ovs-sfc/pom.xml:      <artifactId>sfc-model</artifactId>
./ovs-sfc/pom.xml:              /OSGI-OPT/ovs-sfc/53-ovssfc-provider.xml=${project.basedir}/src/main/resources/initial/53-ovssfc-provider.xml,{maven-resources}


% find . -name pom.xml | xargs grep ovsdb
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:        <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./sfc-karaf/pom.xml:        <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-model/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-model/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:           <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:           <version>${ovsdb.southbound.version}</version>
./sfc-sb-rest/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-netconf/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./pom.xml:        <ovsdb.southbound.version>1.1.1-SNAPSHOT</ovsdb.southbound.version>



_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release



Re: [release] New project build cycle between sfc and ovsdb?

Brady Allen Johnson <brady.allen.johnson@...>
 


SFC definitely uses OVSDB, but I cant imagine why OVSDB would need anything from SFC.

OVSDB used to have some implementation code for SFC, but that should have been removed long ago.

Regards,

Brady


On 06/26/2015 10:34 AM, Thanh Ha wrote:

Hi Everyone,

Just trying to figure out how to solve this build cycle. It seems sfc needs ovsdb and vice-versa causing a build cycle between the 2 projects (see below). How do we resolve this? and is there a way we can re-organize these repos so that this doesn't happen in the future?

Regards,

Thanh

% find . -name pom.xml | xargs grep sfc
./commons/parent/pom.xml:    <ovsdb.ovssfc.version>0.1.1-SNAPSHOT</ovsdb.ovssfc.version>
./commons/parent/pom.xml:              **/openstack/,**/ovs-sfc/,
./features/ovs-sfc/pom.xml:  <artifactId>features-ovs-sfc</artifactId>
./features/pom.xml:    <module>ovs-sfc</module>
./ovs-sfc/pom.xml:  <artifactId>ovssfc</artifactId>
./ovs-sfc/pom.xml:      <groupId>org.opendaylight.sfc</groupId>
./ovs-sfc/pom.xml:      <artifactId>sfc-model</artifactId>
./ovs-sfc/pom.xml:              /OSGI-OPT/ovs-sfc/53-ovssfc-provider.xml=${project.basedir}/src/main/resources/initial/53-ovssfc-provider.xml,{maven-resources}


% find . -name pom.xml | xargs grep ovsdb
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:        <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./sfc-karaf/pom.xml:        <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-model/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-model/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:           <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:           <version>${ovsdb.southbound.version}</version>
./sfc-sb-rest/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-netconf/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./pom.xml:        <ovsdb.southbound.version>1.1.1-SNAPSHOT</ovsdb.southbound.version>



_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release


New project build cycle between sfc and ovsdb?

Thanh Ha <thanh.ha@...>
 

Hi Everyone,

Just trying to figure out how to solve this build cycle. It seems sfc needs ovsdb and vice-versa causing a build cycle between the 2 projects (see below). How do we resolve this? and is there a way we can re-organize these repos so that this doesn't happen in the future?

Regards,

Thanh

% find . -name pom.xml | xargs grep sfc
./commons/parent/pom.xml:    <ovsdb.ovssfc.version>0.1.1-SNAPSHOT</ovsdb.ovssfc.version>
./commons/parent/pom.xml:              **/openstack/,**/ovs-sfc/,
./features/ovs-sfc/pom.xml:  <artifactId>features-ovs-sfc</artifactId>
./features/pom.xml:    <module>ovs-sfc</module>
./ovs-sfc/pom.xml:  <artifactId>ovssfc</artifactId>
./ovs-sfc/pom.xml:      <groupId>org.opendaylight.sfc</groupId>
./ovs-sfc/pom.xml:      <artifactId>sfc-model</artifactId>
./ovs-sfc/pom.xml:              /OSGI-OPT/ovs-sfc/53-ovssfc-provider.xml=${project.basedir}/src/main/resources/initial/53-ovssfc-provider.xml,{maven-resources}


% find . -name pom.xml | xargs grep ovsdb
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features-sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./features-sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./features/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:        <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./features/pom.xml:       <groupId>org.opendaylight.ovsdb</groupId>
./features/pom.xml:       <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:        <groupId>org.opendaylight.ovsdb</groupId>
./sfc-karaf/pom.xml:        <version>${ovsdb.southbound.version}</version>
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-karaf/pom.xml:      <!--<groupId>org.opendaylight.ovsdb</groupId>-->
./sfc-karaf/pom.xml:      <!--<version>${ovsdb.southbound.version}</version>-->
./sfc-model/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-model/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:            <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:            <version>${ovsdb.southbound.version}</version>
./sfc-ovs/pom.xml:           <groupId>org.opendaylight.ovsdb</groupId>
./sfc-ovs/pom.xml:           <version>${ovsdb.southbound.version}</version>
./sfc-sb-rest/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./sfc-netconf/pom.xml:                        <Bundle-Activator>org.opendaylight.ovsdb.plugin.internal.Activator</Bundle-Activator>
./pom.xml:        <ovsdb.southbound.version>1.1.1-SNAPSHOT</ovsdb.southbound.version>


Re: ODL Inventory

Khaldoon Al Zoubi <khaldoon.alzoubi@...>
 

Thanks Sam. Actually, this what I thought I need to do (only include odl-ovsdb-southbound-impl in my features.xml), but I am not sure what part I am missing. I believe the devstack & ODL connection works since I am able to see neutron elements in datastore when executing commands like (neutron net-create net-1). So feature odl-neutron-service works.

However, when I am running ODL purely from the OVSDB project it works and I can see the operational nodes. So, I am missing something in my project.

Thanks Sam as always.

Regards,
Khal

-----Original Message-----
From: Sam Hague [mailto:shague@...]
Sent: Thursday, June 25, 2015 2:41 PM
To: Khaldoon Al Zoubi
Cc: ovsdb-dev@...
Subject: Re: [ovsdb-dev] ODL Inventory

Khal,

the OVSDB southbound plugin [1] will populate the topology with the ovsdb node information, including the bridges and ports. With devstack as part of the local.conf config the ODL address is specified. In the final steps of the stack.sh the OVSDB Manager entry is set to that address and the OVSDB nodes will connect to ODL. The OVSDB southbound plugin will see that connection and begin to populate the MDSAL operational datastore - stores the node, the bridge, the ports as termination points.

From there the netvirt [2] application listens for the operational updates. netvirt also listens on the neutron events coming from the northbound side. With these two sets of events netvirt will satisfy the neutron requests.

The openflow nodes inventory is populated via the openflowplugin. When the OVSDB nodes connect and netvirt sees that it will create the required bridges, i.e, br-int, and then set the Controller address. Those bridges will then connect to ODL openflowplugin port and openflowplugin will add the switches to the inventory.

So you just need the odl-ovsdb-southbound-impl or odl-ovsdb-southbound-impl-ui feature to get the southbound plugin which will get the inventory for you.

Thanks, Sam

[1] ovsdb/southbound/southbound-impl
[2] ovsdb/openstack

----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...>
To: ovsdb-dev@...
Sent: Thursday, June 25, 2015 12:15:05 PM
Subject: [ovsdb-dev] ODL Inventory



Hi,



I can’t figure out how OVSDB populate ODL Inventory based on openstack (i.e.
specifically after ./stack.sh is complete). Also, is there a feature I can
include in my project to do that.



Thanks much.

Khal

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: ODL Inventory

Sam Hague
 

Khal,

the OVSDB southbound plugin [1] will populate the topology with the ovsdb node information, including the bridges and ports. With devstack as part of the local.conf config the ODL address is specified. In the final steps of the stack.sh the OVSDB Manager entry is set to that address and the OVSDB nodes will connect to ODL. The OVSDB southbound plugin will see that connection and begin to populate the MDSAL operational datastore - stores the node, the bridge, the ports as termination points.

From there the netvirt [2] application listens for the operational updates. netvirt also listens on the neutron events coming from the northbound side. With these two sets of events netvirt will satisfy the neutron requests.

The openflow nodes inventory is populated via the openflowplugin. When the OVSDB nodes connect and netvirt sees that it will create the required bridges, i.e, br-int, and then set the Controller address. Those bridges will then connect to ODL openflowplugin port and openflowplugin will add the switches to the inventory.

So you just need the odl-ovsdb-southbound-impl or odl-ovsdb-southbound-impl-ui feature to get the southbound plugin which will get the inventory for you.

Thanks, Sam

[1] ovsdb/southbound/southbound-impl
[2] ovsdb/openstack

----- Original Message -----
From: "Khaldoon Al Zoubi" <khaldoon.alzoubi@...>
To: ovsdb-dev@...
Sent: Thursday, June 25, 2015 12:15:05 PM
Subject: [ovsdb-dev] ODL Inventory



Hi,



I can’t figure out how OVSDB populate ODL Inventory based on openstack (i.e.
specifically after ./stack.sh is complete). Also, is there a feature I can
include in my project to do that.



Thanks much.

Khal

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


ODL Inventory

Khaldoon Al Zoubi <khaldoon.alzoubi@...>
 

Hi,

 

I can’t figure out how OVSDB populate ODL Inventory based on openstack (i.e. specifically after ./stack.sh is complete). Also, is there a feature I can include in my project to do that.

 

Thanks much.

Khal


Re: [integration-dev] ovsdb server port

Edward Warnicke <hagbard@...>
 

Thank you for confirming :)

Ed

On Mon, Jun 22, 2015 at 11:14 PM, Anil Vishnoi <vishnoianil@...> wrote:
i tried different ovs port to connect to from controller and it worked fine for me.

On Tue, Jun 23, 2015 at 8:40 AM, Edward Warnicke <hagbard@...> wrote:
If memory serves, we *should* be able to use any port we desire in connection_info when starting a connection from the controller to ovsdb.

That said, to be completely honest, I've never tried any other port... 

Ed

On Mon, Jun 22, 2015 at 6:34 PM, Luis Gomez <ecelgp@...> wrote:
Hi Sam, controller is always tested with 6640, I am just talking on the OVS side.


> On Jun 22, 2015, at 4:59 PM, Sam Hague <shague@...> wrote:
>
> Luis,
>
> when you say ovsdb suite, does that include the southbound and the netvirt pieces?
>
> Also, have both pieces already been tested with 6634 as the controller ovsdb port? Reason I ask, is there might some hardcoded values in the ovsdb code depending on the use case.
>
> Thanks, Sam
>
> ----- Original Message -----
>> From: "Luis Gomez" <ecelgp@...>
>> To: "Andrew Grimberg" <agrimberg@...>
>> Cc: "'integration-dev@...' (integration-dev@...)
>> (integration-dev@...) (integration-dev@...)"
>> <integration-dev@...>, "ovsdb-dev" <ovsdb-dev@...>
>> Sent: Monday, June 22, 2015 6:36:10 PM
>> Subject: Re: [ovsdb-dev] [integration-dev] ovsdb server port
>>
>> So if we want the OVSDB suite to run smooth in a test consolidated
>> environment (controller + OVS in same VM) we will have to open a different
>> port (not 6640) for the mininet VM. So I am thinking we can still use the
>> old port 6634 for the mininet VM.
>>
>> BR/Luis
>>
>>
>>
>>
>> On Jun 22, 2015, at 3:05 PM, Andrew Grimberg < agrimberg@...
>>> wrote:
>>
>> On Mon, 2015-06-22 at 15:30 -0600, Edward Warnicke wrote:
>>
>>
>> Luis,
>>
>> From the RFC: https://tools.ietf.org/html/rfc7047
>>
>> "IANA has assigned TCP port 6640 for this protocol. Earlier
>>
>> implementations of OVSDB used another port number, but compliant
>> implementations should use the IANA-assigned number.
>>
>> IANA has updated the reference for port 6640 to point to this
>> document."
>>
>>
>> My guess is that it might have been 6634 at some point in the past...
>> but its 6640 now.
>>
>> How old is our RHEL?
>>
>> Ed,
>>
>> This is a fallout from the recently built Fedora 21. Yes, we're aware
>> that F22 is already available but it came out just after we built out
>> the F21 image. We can modify the port that SELinux allows (it's not
>> hard), just not what the default SELinux policies allow openvswitch to
>> use.
>>
>> If IANA says it should be 6640, I would suggest we use that and just
>> modify the Jenkins script to add it as an allowed port.
>>
>> -Andy-
>>
>> --
>> Andrew J Grimberg
>> Systems Administrator
>> The Linux Foundation
>>
>>
>> _______________________________________________
>> ovsdb-dev mailing list
>> ovsdb-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
>>

_______________________________________________


_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev




--
Thanks
Anil


Fw: Invitation to WebEx meeting: OVSDB VTEP Mtg (hardware_vtep)

daya k
 

all,

we are starting an ongoing sync up call at 7 am PST tuesdays, to implement hardware_vtep schema to the ovsdb project. please find meeting details attached.
here's the agenda set from initial kick-off meeting-

-          Hardware_vtep schema md-sal model scoped to ovsdb project
-          Net-virt module updates to support the schema and tie it to neutron NSF
-          AI  : Maruti to provide L2-gateway functionality overview, and share thoughts on how ODL agent could be implemented after discussing with Armando etc.
-          Initial testing of the project can start with OVS, schema can be loaded manually,  and the emulator script Sumit has attached (posted on forum by Sam Hague)
-          Statistics and L3 support - phase 2
-          Need to start work on Project proposal and wiki

 thanks!
daya



----- Forwarded Message -----
From: Phil Robb via Cisco WebEx <admin@...>
To: daya_k@...
Sent: Tuesday, June 23, 2015 10:11 AM
Subject: Invitation to WebEx meeting: OVSDB VTEP Mtg

Cisco WebEx logo
Hi daya k,
 
Phil Robb is inviting you to this WebEx meeting:
  
OVSDB VTEP Mtg
Every Tuesday, from Tue, Jun 23, 2015 to no end date, 7:00 am | 1 hr
San Francisco (Pacific Daylight Time, GMT-07:00)
Host: Phil Robb
  
 
Add the attached iCalendar (.ics) file to your calendar.
 
Agenda
This meeting does not have an agenda.
 
Access Information
Where: WebEx Online
Meeting number: 195 495 594
Password: This meeting does not require a password.
 
Audio Connection
1-855-244-8681 Call-in toll-free number (US/Canada)
1-650-479-3207 Call-in toll number (US/Canada)
Access code: 195 495 594
Need more numbers or information? Check out toll-free calling restrictions.
Can't access your meeting? Get help.
Delivering the power of collaboration
Cisco WebEx Team
Footer
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the meeting to be recorded. By joining this meeting, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the meeting. Please note that any such recordings may be subject to discovery in the event of litigation.

©2015 Cisco and/or its affiliates. All rights reserved.
MT-A-001
Cisco





Re: [integration-dev] ovsdb server port

Anil Vishnoi
 

i tried different ovs port to connect to from controller and it worked fine for me.

On Tue, Jun 23, 2015 at 8:40 AM, Edward Warnicke <hagbard@...> wrote:
If memory serves, we *should* be able to use any port we desire in connection_info when starting a connection from the controller to ovsdb.

That said, to be completely honest, I've never tried any other port... 

Ed

On Mon, Jun 22, 2015 at 6:34 PM, Luis Gomez <ecelgp@...> wrote:
Hi Sam, controller is always tested with 6640, I am just talking on the OVS side.


> On Jun 22, 2015, at 4:59 PM, Sam Hague <shague@...> wrote:
>
> Luis,
>
> when you say ovsdb suite, does that include the southbound and the netvirt pieces?
>
> Also, have both pieces already been tested with 6634 as the controller ovsdb port? Reason I ask, is there might some hardcoded values in the ovsdb code depending on the use case.
>
> Thanks, Sam
>
> ----- Original Message -----
>> From: "Luis Gomez" <ecelgp@...>
>> To: "Andrew Grimberg" <agrimberg@...>
>> Cc: "'integration-dev@...' (integration-dev@...)
>> (integration-dev@...) (integration-dev@...)"
>> <integration-dev@...>, "ovsdb-dev" <ovsdb-dev@...>
>> Sent: Monday, June 22, 2015 6:36:10 PM
>> Subject: Re: [ovsdb-dev] [integration-dev] ovsdb server port
>>
>> So if we want the OVSDB suite to run smooth in a test consolidated
>> environment (controller + OVS in same VM) we will have to open a different
>> port (not 6640) for the mininet VM. So I am thinking we can still use the
>> old port 6634 for the mininet VM.
>>
>> BR/Luis
>>
>>
>>
>>
>> On Jun 22, 2015, at 3:05 PM, Andrew Grimberg < agrimberg@...
>>> wrote:
>>
>> On Mon, 2015-06-22 at 15:30 -0600, Edward Warnicke wrote:
>>
>>
>> Luis,
>>
>> From the RFC: https://tools.ietf.org/html/rfc7047
>>
>> "IANA has assigned TCP port 6640 for this protocol. Earlier
>>
>> implementations of OVSDB used another port number, but compliant
>> implementations should use the IANA-assigned number.
>>
>> IANA has updated the reference for port 6640 to point to this
>> document."
>>
>>
>> My guess is that it might have been 6634 at some point in the past...
>> but its 6640 now.
>>
>> How old is our RHEL?
>>
>> Ed,
>>
>> This is a fallout from the recently built Fedora 21. Yes, we're aware
>> that F22 is already available but it came out just after we built out
>> the F21 image. We can modify the port that SELinux allows (it's not
>> hard), just not what the default SELinux policies allow openvswitch to
>> use.
>>
>> If IANA says it should be 6640, I would suggest we use that and just
>> modify the Jenkins script to add it as an allowed port.
>>
>> -Andy-
>>
>> --
>> Andrew J Grimberg
>> Systems Administrator
>> The Linux Foundation
>>
>>
>> _______________________________________________
>> ovsdb-dev mailing list
>> ovsdb-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
>>

_______________________________________________


_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev




--
Thanks
Anil


Re: [integration-dev] ovsdb server port

Edward Warnicke <hagbard@...>
 

If memory serves, we *should* be able to use any port we desire in connection_info when starting a connection from the controller to ovsdb.

That said, to be completely honest, I've never tried any other port... 

Ed

On Mon, Jun 22, 2015 at 6:34 PM, Luis Gomez <ecelgp@...> wrote:
Hi Sam, controller is always tested with 6640, I am just talking on the OVS side.


> On Jun 22, 2015, at 4:59 PM, Sam Hague <shague@...> wrote:
>
> Luis,
>
> when you say ovsdb suite, does that include the southbound and the netvirt pieces?
>
> Also, have both pieces already been tested with 6634 as the controller ovsdb port? Reason I ask, is there might some hardcoded values in the ovsdb code depending on the use case.
>
> Thanks, Sam
>
> ----- Original Message -----
>> From: "Luis Gomez" <ecelgp@...>
>> To: "Andrew Grimberg" <agrimberg@...>
>> Cc: "'integration-dev@...' (integration-dev@...)
>> (integration-dev@...) (integration-dev@...)"
>> <integration-dev@...>, "ovsdb-dev" <ovsdb-dev@...>
>> Sent: Monday, June 22, 2015 6:36:10 PM
>> Subject: Re: [ovsdb-dev] [integration-dev] ovsdb server port
>>
>> So if we want the OVSDB suite to run smooth in a test consolidated
>> environment (controller + OVS in same VM) we will have to open a different
>> port (not 6640) for the mininet VM. So I am thinking we can still use the
>> old port 6634 for the mininet VM.
>>
>> BR/Luis
>>
>>
>>
>>
>> On Jun 22, 2015, at 3:05 PM, Andrew Grimberg < agrimberg@...
>>> wrote:
>>
>> On Mon, 2015-06-22 at 15:30 -0600, Edward Warnicke wrote:
>>
>>
>> Luis,
>>
>> From the RFC: https://tools.ietf.org/html/rfc7047
>>
>> "IANA has assigned TCP port 6640 for this protocol. Earlier
>>
>> implementations of OVSDB used another port number, but compliant
>> implementations should use the IANA-assigned number.
>>
>> IANA has updated the reference for port 6640 to point to this
>> document."
>>
>>
>> My guess is that it might have been 6634 at some point in the past...
>> but its 6640 now.
>>
>> How old is our RHEL?
>>
>> Ed,
>>
>> This is a fallout from the recently built Fedora 21. Yes, we're aware
>> that F22 is already available but it came out just after we built out
>> the F21 image. We can modify the port that SELinux allows (it's not
>> hard), just not what the default SELinux policies allow openvswitch to
>> use.
>>
>> If IANA says it should be 6640, I would suggest we use that and just
>> modify the Jenkins script to add it as an allowed port.
>>
>> -Andy-
>>
>> --
>> Andrew J Grimberg
>> Systems Administrator
>> The Linux Foundation
>>
>>
>> _______________________________________________
>> ovsdb-dev mailing list
>> ovsdb-dev@...
>> https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
>>

_______________________________________________


Re: [integration-dev] ovsdb server port

Luis Gomez
 

Hi Sam, controller is always tested with 6640, I am just talking on the OVS side.

On Jun 22, 2015, at 4:59 PM, Sam Hague <shague@...> wrote:

Luis,

when you say ovsdb suite, does that include the southbound and the netvirt pieces?

Also, have both pieces already been tested with 6634 as the controller ovsdb port? Reason I ask, is there might some hardcoded values in the ovsdb code depending on the use case.

Thanks, Sam

----- Original Message -----
From: "Luis Gomez" <ecelgp@...>
To: "Andrew Grimberg" <agrimberg@...>
Cc: "'integration-dev@...' (integration-dev@...)
(integration-dev@...) (integration-dev@...)"
<integration-dev@...>, "ovsdb-dev" <ovsdb-dev@...>
Sent: Monday, June 22, 2015 6:36:10 PM
Subject: Re: [ovsdb-dev] [integration-dev] ovsdb server port

So if we want the OVSDB suite to run smooth in a test consolidated
environment (controller + OVS in same VM) we will have to open a different
port (not 6640) for the mininet VM. So I am thinking we can still use the
old port 6634 for the mininet VM.

BR/Luis




On Jun 22, 2015, at 3:05 PM, Andrew Grimberg < agrimberg@...
wrote:
On Mon, 2015-06-22 at 15:30 -0600, Edward Warnicke wrote:


Luis,

From the RFC: https://tools.ietf.org/html/rfc7047

"IANA has assigned TCP port 6640 for this protocol. Earlier

implementations of OVSDB used another port number, but compliant
implementations should use the IANA-assigned number.

IANA has updated the reference for port 6640 to point to this
document."


My guess is that it might have been 6634 at some point in the past...
but its 6640 now.

How old is our RHEL?

Ed,

This is a fallout from the recently built Fedora 21. Yes, we're aware
that F22 is already available but it came out just after we built out
the F21 image. We can modify the port that SELinux allows (it's not
hard), just not what the default SELinux policies allow openvswitch to
use.

If IANA says it should be 6640, I would suggest we use that and just
modify the Jenkins script to add it as an allowed port.

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: [integration-dev] ovsdb server port

Sam Hague
 

Luis,

when you say ovsdb suite, does that include the southbound and the netvirt pieces?

Also, have both pieces already been tested with 6634 as the controller ovsdb port? Reason I ask, is there might some hardcoded values in the ovsdb code depending on the use case.

Thanks, Sam

----- Original Message -----
From: "Luis Gomez" <ecelgp@...>
To: "Andrew Grimberg" <agrimberg@...>
Cc: "'integration-dev@...' (integration-dev@...)
(integration-dev@...) (integration-dev@...)"
<integration-dev@...>, "ovsdb-dev" <ovsdb-dev@...>
Sent: Monday, June 22, 2015 6:36:10 PM
Subject: Re: [ovsdb-dev] [integration-dev] ovsdb server port

So if we want the OVSDB suite to run smooth in a test consolidated
environment (controller + OVS in same VM) we will have to open a different
port (not 6640) for the mininet VM. So I am thinking we can still use the
old port 6634 for the mininet VM.

BR/Luis




On Jun 22, 2015, at 3:05 PM, Andrew Grimberg < agrimberg@...
wrote:
On Mon, 2015-06-22 at 15:30 -0600, Edward Warnicke wrote:


Luis,

From the RFC: https://tools.ietf.org/html/rfc7047

"IANA has assigned TCP port 6640 for this protocol. Earlier

implementations of OVSDB used another port number, but compliant
implementations should use the IANA-assigned number.

IANA has updated the reference for port 6640 to point to this
document."


My guess is that it might have been 6634 at some point in the past...
but its 6640 now.

How old is our RHEL?

Ed,

This is a fallout from the recently built Fedora 21. Yes, we're aware
that F22 is already available but it came out just after we built out
the F21 image. We can modify the port that SELinux allows (it's not
hard), just not what the default SELinux policies allow openvswitch to
use.

If IANA says it should be 6640, I would suggest we use that and just
modify the Jenkins script to add it as an allowed port.

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev


Re: [integration-dev] ovsdb server port

Andrew Grimberg <agrimberg@...>
 

On Mon, 2015-06-22 at 15:36 -0700, Luis Gomez wrote:
So if we want the OVSDB suite to run smooth in a test consolidated
environment (controller + OVS in same VM) we will have to open a
different port (not 6640) for the mininet VM. So I am thinking we can
still use the old port 6634 for the mininet VM.
Ah, ok, then yes, 6634 would be acceptable as that's what the system is
currently configured for.

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


Re: [integration-dev] ovsdb server port

Luis Gomez
 

So if we want the OVSDB suite to run smooth in a test consolidated environment (controller + OVS in same VM) we will have to open a different port (not 6640) for the mininet VM. So I am thinking we can still use the old port 6634 for the mininet VM.

BR/Luis

On Jun 22, 2015, at 3:05 PM, Andrew Grimberg <agrimberg@...> wrote:

On Mon, 2015-06-22 at 15:30 -0600, Edward Warnicke wrote:
Luis,

From the RFC: https://tools.ietf.org/html/rfc7047

"IANA has assigned TCP port 6640 for this protocol. Earlier

  implementations of OVSDB used another port number, but compliant
  implementations should use the IANA-assigned number.

  IANA has updated the reference for port 6640 to point to this
  document."


My guess is that it might have been 6634 at some point in the past...
but its 6640 now.

How old is our RHEL?

Ed,

This is a fallout from the recently built Fedora 21. Yes, we're aware
that F22 is already available but it came out just after we built out
the F21 image. We can modify the port that SELinux allows (it's not
hard), just not what the default SELinux policies allow openvswitch to
use.

If IANA says it should be 6640, I would suggest we use that and just
modify the Jenkins script to add it as an allowed port.

-Andy-

-- 
Andrew J Grimberg
Systems Administrator
The Linux Foundation


Re: [integration-dev] ovsdb server port

Andrew Grimberg <agrimberg@...>
 

On Mon, 2015-06-22 at 15:30 -0600, Edward Warnicke wrote:
Luis,

From the RFC: https://tools.ietf.org/html/rfc7047

"IANA has assigned TCP port 6640 for this protocol. Earlier

implementations of OVSDB used another port number, but compliant
implementations should use the IANA-assigned number.

IANA has updated the reference for port 6640 to point to this
document."


My guess is that it might have been 6634 at some point in the past...
but its 6640 now.

How old is our RHEL?
Ed,

This is a fallout from the recently built Fedora 21. Yes, we're aware
that F22 is already available but it came out just after we built out
the F21 image. We can modify the port that SELinux allows (it's not
hard), just not what the default SELinux policies allow openvswitch to
use.

If IANA says it should be 6640, I would suggest we use that and just
modify the Jenkins script to add it as an allowed port.

-Andy-

--
Andrew J Grimberg
Systems Administrator
The Linux Foundation


Re: [integration-dev] ovsdb server port

Edward Warnicke <hagbard@...>
 

Luis,


"IANA has assigned TCP port 6640 for this protocol. Earlier
   implementations of OVSDB used another port number, but compliant
   implementations should use the IANA-assigned number.

   IANA has updated the reference for port 6640 to point to this
   document."

My guess is that it might have been 6634 at some point in the past... but its 6640 now.
How old is our RHEL?

Ed

On Mon, Jun 22, 2015 at 3:26 PM, Luis Gomez <ecelgp@...> wrote:
Hi ovsdb experts,

Anyone knows if there is any agreement on standard OVSDB server port. Our controller uses 6640 while SELinux assumes 6634 for example.

BR/Luis
_______________________________________________
integration-dev mailing list
integration-dev@...
https://lists.opendaylight.org/mailman/listinfo/integration-dev


ovsdb server port

Luis Gomez
 

Hi ovsdb experts,

Anyone knows if there is any agreement on standard OVSDB server port. Our controller uses 6640 while SELinux assumes 6634 for example.

BR/Luis


Updated Invitation: OVSDB VTEP meeting @ Weekly from 7am to 8am on Tuesday (abhijitkoss@gmail.com)

Abhijit Kumbhare
 

This event has been changed.

OVSDB VTEP meeting

Changed: OVSDB VTEP Mtg
Every Tuesday, from Tue, Jun 23, 2015 to no end date, 8:00 am | 1 hr

Denver (Mountain Daylight Time, GMT-06:00)
Host: Phil Robb

When it's time, start the meeting from here:
https://meetings.webex.com/collabs/meetings/join?uuid=MELBFP47HYGRPFP24RLWVG5NUJ-9VIB


Agenda
This meeting does not have an agenda.

Access Information
Where: WebEx Online
Meeting number: 195 495 594
Meeting password: This meeting does not require a password.
Host key: 401682 (Use this key in the meeting if you have made someone else the host and then want to reclaim the host role.)

Audio Connection
1-855-244-8681 Call-in toll-free number (US/Canada)
1-650-479-3207 Call-in toll number (US/Canada)
Access code: 195 495 594

When
Weekly from 7am to 8am on Tuesday Pacific Time
Where
Changed: Webex (map)
Calendar
abhijitkoss@...
Who
Abhijit Kumbhare - organizer
Philip Robb
shague@...
ovsdb-dev@...

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account ovsdb-dev@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3221 - 3240 of 4855