Re: [OpenDaylight Discuss] [Odlparent-dev] Adopting maven-3.5.x as a build requirement

2018-02-08 Thread Thanh Ha 
On Thu, Feb 8, 2018 at 4:24 PM, Robert Varga  wrote:

> maven-3.5 is being shipped in Fedora 27 and will ship in Ubuntu 18.04
> LTS. I have not done any research beyond that, but as Michael recently
> noted, managing these sorts of dependencies can be done via
> http://sdkman.io/ or similar (although their HTTPS site does not work,
> which is worrysome).
>

skdman sounds like a good find and might be worth investigating to put into
our build images. One worry I have though is we are required to use OpenJDK
and this page http://sdkman.io/sdks.html seems to indicate that it will
install OracleJDK. Has anyone used this to install OpenJDK before?

Thanh
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

[OpenDaylight Discuss] Adopting maven-3.5.x as a build requirement

2018-02-08 Thread Robert Varga 
Hello everyone,

recent issues encountered and our general historical use of everything
latest-and-greatest, we need to discuss timing of making maven-3.5
required for building OpenDaylight.

We currently support and verify maven-3.3.9, which is used for all of
our jobs except those running on odlparent master, which hosts
odlparent-4.0.0-SNAPSHOT.

The reason odlparent-4.0.0 is going to require maven 3.5.0 is SpotBugs,
which does not work with maven-3.3.9 -- that dependency needed to be
updated to move us from a release candidate to a proper release (and to
the next bugfix release).

maven-3.5 is being shipped in Fedora 27 and will ship in Ubuntu 18.04
LTS. I have not done any research beyond that, but as Michael recently
noted, managing these sorts of dependencies can be done via
http://sdkman.io/ or similar (although their HTTPS site does not work,
which is worrysome).

From yang-maven-plugin perspective, the newer the maven the better and
the aether stack has been a world of pain 3.5.x will bring us closer to
ending.

With that, the question is: should we start to require[1] maven 3.5.0[2]
at the beginning of the next development cycle?

Thanks,
Robert

[1] This means running all Jenkins jobs with mvn35 and having maven
enforcer plugin fail build with anything below 3.5.0

[2] Version 3.5.0, not 3.5.2 because Fedora 27's
maven-3.5.0-6.fc27.noarch does not seem to be affected by the issues
we've seen and with vanilla 3.5.0, so excluding it would be unfair.



signature.asc
Description: OpenPGP digital signature
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] [infrautils-dev] configuration options: blueprint xml or cfg's?

2018-02-08 Thread Michael Vorburger 
Sam, my POV is that most of typical "functional" config actually should be
YANG in DS, clustered and what not.

I prefer defaults in code not in BP XML, just because it means (component)
tests wired with Guice instead of BP pick them up as well, but that is a
minor point.

There are exceptions to this general rule for lower level infrastructure
stuff - metrics is one that comes to mind, also the various Karaf system
config in etc/ files, as well as probably the DS/cluster config itself.

IMHO this is just fine as is (and no plans to do any work in this area,
from me) because I don't really see where those system config knobs would
have to be touched in a running cluster in prod. An installation
orchestator thing (à la TripleO) may set non-defaults in etc/, initially,
only.

HTH.

On 8 Feb 2018 15:59, "Sam Hague"  wrote:

>
>
> On Thu, Feb 8, 2018 at 9:38 AM, Tom Pantelis 
> wrote:
>
>>
>>
>> On Thu, Feb 8, 2018 at 9:24 AM, Sam Hague  wrote:
>>
>>>
>>>
>>> On Thu, Feb 8, 2018 at 9:08 AM, Tom Pantelis 
>>> wrote:
>>>


 On Thu, Feb 8, 2018 at 8:56 AM, Sam Hague  wrote:

>
>
> On Thu, Feb 8, 2018 at 8:54 AM, Sam Hague  wrote:
>
>> What is the preferred or suggested best practice for service level
>> configuration? There are two methods we have been using and would like to
>> know the pros and cons of each. Genius and NetVirt went with the 
>> blueprint
>> xmls and openflowplugin and ovsdb went with the cfg's.
>>
> This seems confusing to end users to have two different methods of
> configuration.
>

 The clustered-app-config has advantages outlined in
 https://wiki.opendaylight.org/view/Using_Blueprint#Applic
 ation_configuration. However it does require the data store so in some
 cases may not want that dependency or can't, like infrautls.   Not sure why
 OFP and ovsdb opted for cfg files - perhaps that was before
 clustered-app-config?

>>> Adding Anil for why ofp and ovsdb used cfg's as he drove that at the
>>> same time. I thought it was because he thought it was easiest to implement
>>> but that we would migrate to xml later.
>>>
>>> That is a good point on the extra dependencies. Seems like xml is better
>>> if you have mdsal and restconf, but you don't have those dependencies in
>>> projects like infrautils. Would it make sense to have some kind of cfg
>>> adapter/wrapper to five capabilities to the cfg users?
>>>


>>>
>> So define a yang model for the cfg options in infrautils in some other
>> project with a DTCL that writes to the cfg file? That seems doable but what
>> project (genius I guess)?  And what happens if someone edits the file
>> locally
>>
> Yes, this is what I was thinking - in genius and it gives the cfg users
> the benefits of the xml stuff. If used, then I think it means the cfg's
> should not be manually modified - all modifications should come through the
> genius xml wrapper. If editted locally, maybe we could write it to mdsal
> also, though I agree it gets messy, so maybe just don't allow that if
> possible.
>
> What happens now if you have multiple ODL nodes and someone edits a cfg on
> one node - does it only impact that node? guess that is the main benefit of
> xml that it is cluster aware. But if the user did do this, it is somewhat
> like your case of if a cfg is manually editted. Seems like you would need
> to update all cfg's right?
>
>
> ___
> infrautils-dev mailing list
> infrautils-...@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/infrautils-dev
>
>
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] configuration options: blueprint xml or cfg's?

2018-02-08 Thread Tom Pantelis 
On Thu, Feb 8, 2018 at 9:59 AM, Sam Hague  wrote:

>
>
> On Thu, Feb 8, 2018 at 9:38 AM, Tom Pantelis 
> wrote:
>
>>
>>
>> On Thu, Feb 8, 2018 at 9:24 AM, Sam Hague  wrote:
>>
>>>
>>>
>>> On Thu, Feb 8, 2018 at 9:08 AM, Tom Pantelis 
>>> wrote:
>>>


 On Thu, Feb 8, 2018 at 8:56 AM, Sam Hague  wrote:

>
>
> On Thu, Feb 8, 2018 at 8:54 AM, Sam Hague  wrote:
>
>> What is the preferred or suggested best practice for service level
>> configuration? There are two methods we have been using and would like to
>> know the pros and cons of each. Genius and NetVirt went with the 
>> blueprint
>> xmls and openflowplugin and ovsdb went with the cfg's.
>>
> This seems confusing to end users to have two different methods of
> configuration.
>

 The clustered-app-config has advantages outlined in
 https://wiki.opendaylight.org/view/Using_Blueprint#Applic
 ation_configuration. However it does require the data store so in some
 cases may not want that dependency or can't, like infrautls.   Not sure why
 OFP and ovsdb opted for cfg files - perhaps that was before
 clustered-app-config?

>>> Adding Anil for why ofp and ovsdb used cfg's as he drove that at the
>>> same time. I thought it was because he thought it was easiest to implement
>>> but that we would migrate to xml later.
>>>
>>> That is a good point on the extra dependencies. Seems like xml is better
>>> if you have mdsal and restconf, but you don't have those dependencies in
>>> projects like infrautils. Would it make sense to have some kind of cfg
>>> adapter/wrapper to five capabilities to the cfg users?
>>>


>>>
>> So define a yang model for the cfg options in infrautils in some other
>> project with a DTCL that writes to the cfg file? That seems doable but what
>> project (genius I guess)?  And what happens if someone edits the file
>> locally
>>
> Yes, this is what I was thinking - in genius and it gives the cfg users
> the benefits of the xml stuff. If used, then I think it means the cfg's
> should not be manually modified - all modifications should come through the
> genius xml wrapper. If editted locally, maybe we could write it to mdsal
> also, though I agree it gets messy, so maybe just don't allow that if
> possible.
>
> What happens now if you have multiple ODL nodes and someone edits a cfg on
> one node - does it only impact that node? guess that is the main benefit of
> xml that it is cluster aware. But if the user did do this, it is somewhat
> like your case of if a cfg is manually editted. Seems like you would need
> to update all cfg's right?
>

Yes you do although I think karaf has a way of distributing cfgs (I recall
a component called "cellar") - but, with the advent of
clustered-app-config,  I never researched it so not sure how it works.
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] configuration options: blueprint xml or cfg's?

2018-02-08 Thread Tom Pantelis 
On Thu, Feb 8, 2018 at 9:24 AM, Sam Hague  wrote:

>
>
> On Thu, Feb 8, 2018 at 9:08 AM, Tom Pantelis 
> wrote:
>
>>
>>
>> On Thu, Feb 8, 2018 at 8:56 AM, Sam Hague  wrote:
>>
>>>
>>>
>>> On Thu, Feb 8, 2018 at 8:54 AM, Sam Hague  wrote:
>>>
 What is the preferred or suggested best practice for service level
 configuration? There are two methods we have been using and would like to
 know the pros and cons of each. Genius and NetVirt went with the blueprint
 xmls and openflowplugin and ovsdb went with the cfg's.

>>> This seems confusing to end users to have two different methods of
>>> configuration.
>>>
>>
>> The clustered-app-config has advantages outlined in
>> https://wiki.opendaylight.org/view/Using_Blueprint#Applic
>> ation_configuration. However it does require the data store so in some
>> cases may not want that dependency or can't, like infrautls.   Not sure why
>> OFP and ovsdb opted for cfg files - perhaps that was before
>> clustered-app-config?
>>
> Adding Anil for why ofp and ovsdb used cfg's as he drove that at the same
> time. I thought it was because he thought it was easiest to implement but
> that we would migrate to xml later.
>
> That is a good point on the extra dependencies. Seems like xml is better
> if you have mdsal and restconf, but you don't have those dependencies in
> projects like infrautils. Would it make sense to have some kind of cfg
> adapter/wrapper to five capabilities to the cfg users?
>
>>
>>
>
So define a yang model for the cfg options in infrautils in some other
project with a DTCL that writes to the cfg file? That seems doable but what
project (genius I guess)?  And what happens if someone edits the file
locally
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] configuration options: blueprint xml or cfg's?

2018-02-08 Thread Sam Hague 
On Thu, Feb 8, 2018 at 9:08 AM, Tom Pantelis  wrote:

>
>
> On Thu, Feb 8, 2018 at 8:56 AM, Sam Hague  wrote:
>
>>
>>
>> On Thu, Feb 8, 2018 at 8:54 AM, Sam Hague  wrote:
>>
>>> What is the preferred or suggested best practice for service level
>>> configuration? There are two methods we have been using and would like to
>>> know the pros and cons of each. Genius and NetVirt went with the blueprint
>>> xmls and openflowplugin and ovsdb went with the cfg's.
>>>
>> This seems confusing to end users to have two different methods of
>> configuration.
>>
>
> The clustered-app-config has advantages outlined in
> https://wiki.opendaylight.org/view/Using_Blueprint#Applic
> ation_configuration. However it does require the data store so in some
> cases may not want that dependency or can't, like infrautls.   Not sure why
> OFP and ovsdb opted for cfg files - perhaps that was before
> clustered-app-config?
>
Adding Anil for why ofp and ovsdb used cfg's as he drove that at the same
time. I thought it was because he thought it was easiest to implement but
that we would migrate to xml later.

That is a good point on the extra dependencies. Seems like xml is better if
you have mdsal and restconf, but you don't have those dependencies in
projects like infrautils. Would it make sense to have some kind of cfg
adapter/wrapper to five capabilities to the cfg users?

>
>
>>
>>> 1. blueprint xml
>>> - more odl/mdsal like since they are yang files
>>> - can be cluster aware - not sure on this
>>>
>>> 2. cfg's
>>> - simple text file rather than xml
>>> - have to explicitly add them to each odl node, could have conflicts
>>>
>>> Thanks, Sam
>>>
>>
>>
>> ___
>> Discuss mailing list
>> Discuss@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/discuss
>>
>>
>
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] configuration options: blueprint xml or cfg's?

2018-02-08 Thread Tom Pantelis 
On Thu, Feb 8, 2018 at 9:15 AM, Jamie G.  wrote:

> You could always use Blueprint with Config Management; you're able to
> set default values in BP, than override via config file.
>
> ex:
>
> http://www.osgi.org/xmlns/blueprint/v1.0.0;
>xmlns:cm="http://aries.apache.org/blueprint/xmlns/
> blueprint-cm/v1.1.0">
>
> 
>  
>  
>  
>  https://wiki.opendaylight.org/view/Using_Blueprint#Applicati
> on_configuration.
> > However it does require the data store so in some cases may not want that
> > dependency or can't, like infrautls.   Not sure why OFP and ovsdb opted
> for
> > cfg files - perhaps that was before clustered-app-config?
> >
> >>>
> >>>
> >>> 1. blueprint xml
> >>> - more odl/mdsal like since they are yang files
> >>> - can be cluster aware - not sure on this
> >>>
> >>> 2. cfg's
> >>> - simple text file rather than xml
> >>> - have to explicitly add them to each odl node, could have conflicts
> >>>
> >>> Thanks, Sam
> >>
> >>
> >>
> >> ___
> >> Discuss mailing list
> >> Discuss@lists.opendaylight.org
> >> https://lists.opendaylight.org/mailman/listinfo/discuss
> >>
> >
> >
> > ___
> > Discuss mailing list
> > Discuss@lists.opendaylight.org
> > https://lists.opendaylight.org/mailman/listinfo/discuss
> >
>
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] configuration options: blueprint xml or cfg's?

2018-02-08 Thread Jamie G. 
You could always use Blueprint with Config Management; you're able to
set default values in BP, than override via config file.

ex:

http://www.osgi.org/xmlns/blueprint/v1.0.0;
   
xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0;>


 
 
 
 https://wiki.opendaylight.org/view/Using_Blueprint#Application_configuration.
> However it does require the data store so in some cases may not want that
> dependency or can't, like infrautls.   Not sure why OFP and ovsdb opted for
> cfg files - perhaps that was before clustered-app-config?
>
>>>
>>>
>>> 1. blueprint xml
>>> - more odl/mdsal like since they are yang files
>>> - can be cluster aware - not sure on this
>>>
>>> 2. cfg's
>>> - simple text file rather than xml
>>> - have to explicitly add them to each odl node, could have conflicts
>>>
>>> Thanks, Sam
>>
>>
>>
>> ___
>> Discuss mailing list
>> Discuss@lists.opendaylight.org
>> https://lists.opendaylight.org/mailman/listinfo/discuss
>>
>
>
> ___
> Discuss mailing list
> Discuss@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/discuss
>
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] configuration options: blueprint xml or cfg's?

2018-02-08 Thread Tom Pantelis 
On Thu, Feb 8, 2018 at 8:56 AM, Sam Hague  wrote:

>
>
> On Thu, Feb 8, 2018 at 8:54 AM, Sam Hague  wrote:
>
>> What is the preferred or suggested best practice for service level
>> configuration? There are two methods we have been using and would like to
>> know the pros and cons of each. Genius and NetVirt went with the blueprint
>> xmls and openflowplugin and ovsdb went with the cfg's.
>>
> This seems confusing to end users to have two different methods of
> configuration.
>

The clustered-app-config has advantages outlined in
https://wiki.opendaylight.org/view/Using_Blueprint#Application_configuration.
However it does require the data store so in some cases may not want that
dependency or can't, like infrautls.   Not sure why OFP and ovsdb opted for
cfg files - perhaps that was before clustered-app-config?


>
>> 1. blueprint xml
>> - more odl/mdsal like since they are yang files
>> - can be cluster aware - not sure on this
>>
>> 2. cfg's
>> - simple text file rather than xml
>> - have to explicitly add them to each odl node, could have conflicts
>>
>> Thanks, Sam
>>
>
>
> ___
> Discuss mailing list
> Discuss@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/discuss
>
>
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] configuration options: blueprint xml or cfg's?

2018-02-08 Thread Sam Hague 
On Thu, Feb 8, 2018 at 8:54 AM, Sam Hague  wrote:

> What is the preferred or suggested best practice for service level
> configuration? There are two methods we have been using and would like to
> know the pros and cons of each. Genius and NetVirt went with the blueprint
> xmls and openflowplugin and ovsdb went with the cfg's.
>
This seems confusing to end users to have two different methods of
configuration.

>
> 1. blueprint xml
> - more odl/mdsal like since they are yang files
> - can be cluster aware - not sure on this
>
> 2. cfg's
> - simple text file rather than xml
> - have to explicitly add them to each odl node, could have conflicts
>
> Thanks, Sam
>
___
Discuss mailing list
Discuss@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/discuss

Re: [OpenDaylight Discuss] Multiple Controller implementation

2018-02-08 Thread Mohamed Abdel Metaal 
Jamo,

Thank you alot i’ll try docker as mentioned by Luis :)


From: Jamo Luhrsen 
Sent: Thursday, February 8, 2018 7:16:28 AM
To: Mohamed Abdel Metaal; Luis Gomez
Cc: discuss@lists.opendaylight.org; openflowplugin-dev
Subject: Re: [OpenDaylight Discuss] Multiple Controller implementation

Ok Mohamed, I see what you are trying to do.

I think it should be possible to build your own version of OpenDaylight that
uses different ports to listen for openflow, and maybe not too difficult.

but there are other ports being used in other places of OpenDaylight
that you would have to change as well to make everything play nice on
the same system like the port restconf listens on, for example.

Luis' idea is pretty reasonable. Try docker.

  
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhub.docker.com%2Fu%2Fopendaylight%2F=02%7C01%7C%7C2abdcf2c6de24bdafbb408d56ebb7ebc%7C84df9e7fe9f640afb435%7C1%7C0%7C636536673912960766=Z2XPvXvvnxrP0fUMFtOPY808uIrGNgcAi5cKv091uGs%3D=0

you could have three ODL containers running on the same system. Each
would get their own local ip and you could point your mininet script
to those specific ips and still use the expected ports.

Thanks,
JamO



On 2/7/18 5:24 PM, Mohamed Abdel Metaal wrote:
> Thanks Luis. This answers my question so far as I thought I could modify the 
> ports in a multiple of configuration files
> in order to achieve this.
>
> Probably this could be a future idea to implement in OpenDaylight that allows 
> a single machine to operate multiple
> controllers simultaneously 
>
>
>
>
>
> *From: *Luis Gomez 
> *Sent: *Thursday, February 8, 2018 2:16
> *To: *Mohamed Abdel Metaal 
> *Cc: *Jamo Luhrsen ; 
> discuss@lists.opendaylight.org ;
> openflowplugin-dev 
> *Subject: *Re: [OpenDaylight Discuss] Multiple Controller implementation
>
>
>
>
>
> On Feb 7, 2018, at 5:11 PM, Mohamed Abdel Metaal  > wrote:
>
>
>
> Luis,
>
>
>
> This could not be possible as all controllers in this case will connect 
> to the same openflow ports, RESTCONF,
> Jolokia ports 8081 and 8080 along with other ports too, so the other 2 
> controllers will address ports which is
> already being addressed by the first controller. It would only be 
> possible to work if these ports are changed in
> each of the other controllers so they don’t collide using the same ports, 
> eg. Openflow ports 6633 / 6653. Just to
> clarify, as I have forgot, I am implementing this using my Ubuntu machine 
> without the use of virtual machines.
> That’s another question, could this be implemented using only my local 
> machine without virtual machines and tweaking
> the ports in each OpenDaylight folder (for each controller)?
>
>
>
> I do not think you can bring more than one controller instance in same 
> machine unless you use VMs or docker. on both
> options you do not need to modify controller ports.
>
>
>
>
>
> Jamo,
>
>
>
> I am currently implementing the controllers in one machine so they have 
> the same address to address the controllers
> (which is the loopback address in my case). So the controllers in my 
> mininet script have the same ip address but
> different openflow ports 6653, 7753 and 8853. Again, probably the same 
> question arises, is multiple controllers only
> possible to implement using different virtual machines per controller?
>
>
>
> Thanks 
>
>
>
> P.S. I have implemented the same implementation before using Floodlight 
> and there was a certain number of ports,
> including openflow ports, that needs to be changed. All using my local 
> machine without the need for virtual machines.
>
> If this is possible then it could be also a great idea to benchmark 
> OpenDaylight with other SDN controllers for
> behavior using a physically distributed control plane.
>
>
>
>
>
> *From: *Jamo Luhrsen 
> *Sent: *Thursday, February 8, 2018 1:53
> *To: *Luis Gomez ; Mohamed Abdel Metaal 
> 
> *Cc: *discuss@lists.opendaylight.org 
> ; openflowplugin-dev
> 
> *Subject: *Re: [OpenDaylight Discuss] Multiple Controller implementation
>
>
>
>
>
> On 2/7/18 4:24 PM, Luis Gomez wrote:
> >
> >> On Feb 7, 2018, at 4:09 PM, Mohamed Abdel Metaal  > wrote:
> >>
> >> Hello Jamo,
> >>
> >> Yes exactly, I have one instance of mininet running that should be 
> connected to 3 opendaylight controllers. In my
> >> mininet python script i