Re: [vpp-dev] Please Call DigSafe...

[Marco Varlese]

On Fri, 2017-11-17 at 09:59 -0500, Dave Barach wrote:
> Dear Marco,
> 
> Good ideas. 
> 
> We could also consider public patches, -2ed by the submitter, with commit
> headlines of the form "RFC: add the XYZ feature." 
+1

> The only downside: each new patch set will kick off the verify jobs. I wonder
> if one could remove "fd.io JJB" quickly enough to keep that from happening.
Somehow, I cannot remove the "fd.io JJB" job at all on my patch submission... :(
> 
> Thanks... D.
Cheers,
Marco
> 
> -Original Message-
> From: Marco Varlese [mailto:mvarl...@suse.de] 
> Sent: Friday, November 17, 2017 9:49 AM
> To: Luke, Chris ; Dave Barach ; vpp-
> d...@lists.fd.io
> Subject: Re: [vpp-dev] Please Call DigSafe...
> 
> Hi Chris / Dave,
> 
> Few thoughts inline...
> 
> On Fri, 2017-11-17 at 13:51 +, Luke, Chris wrote:
> > Hi Dave,
> > 
> > After spending a few minutes to work out that you were talking about a
> > proposed patch and not something any of us had merged (and, especially not
> > that I merged!), I see that what we need is a balance between not
> > discouraging
> > people to experiment, or submit their ideas, but to also steer people
> > towards
> > relevant leads before they get in too deep.
> > 
> > Problem is, if people make huge patches before ever talking to someone, our
> > first contact is when they submit it. The teaching moment is when the
> > reviewer
> > notices it. That is obviously too late for the first patch, but should help
> > with subsequent work.
> > 
> > This is why open source generally prefers people to keep their patches small
> > and thematic; most reviewers tire of seeing many large patches when they are
> > developed in isolation and are directionally unsound - to the point that
> > they
> > start to see the color bar in the review list and if it's yellow-or-worse,
> > and
> > not from someone they specifically associate with quality work, typically
> > those submissions end up ignored.
> 
> Maybe, a point to consider to come up with a "process" is whether the patch is
> addressing existing code (e.g. bug-fix / enhancement) or is a brand-new
> feature.
> 
> I would expect - as you stated - to see small (small to be quantified) patches
> to fix a bug in existing code and considerably bigger patches when adding in a
> new feature although - sometimes - finding a way to split code into multiple
> subsequent patches might be doable. Usually, the impact of a new feature
> should
> be considerably smaller (to existing code path executions) hence a big-fat
> patch
> might be acceptable...
> 
> We could use the DRAFT feature in "git review". That is very similar to the
> RFC
> (Request For Comments) method used in other projects. It might be a decent way
> to get early feedback and work on the design with key people...
> > 
> > I don't think we have contribution guidelines for VPP or fd.io in general
> > (apart from the style and doc guides); at least a very quick scan of the
> > wiki
> > was not fruitful. We should have somewhere to send new people (can we nudge
> > people who login to Gerrit for the first time?), and also people whose first
> > submission is unacceptable (too big, too complex, directionally unsound).
> > And
> > we as reviewers should remain vigilant and, importantly, consistent.
> 
> Maybe, we could have a process which starts with a DRAFT-type patch to give
> time
> to core reviewers to understand what's going on.
> Beside the patch size topic, another item I would consider is the
> length/quality
> of COMMENTS in the patch; it's pretty common (and not just to FD.io/VPP
> projects) to see very brief comments to patches which can make reviewers' life
> miserable (and after 2 days that patch-comment would mean nothing even to the
> author). IMHO that should be a straight -1...
> I am quite a new contributor to VPP but a process I built in my mind over the
> past few weeks is split into two sections and looks like:
> 
> == NEW FEATURE DEVELOPMENT == 
> 1) Reach out to core people (Dave / Damjan / Ed / Florin / Dave W / Chris /
> etc.) to understand feasibility of the proposed feature;
> 2) Write your patch (including unit-tests where applicable)
> 3) Fix coding style (make fixstyle)
> 4) Check your COMMENTS (do they reflect the code submitted? the longer the
> explanation the better)
> 5) Submit DRAFT patch to gerrit
> 6) Address any early comments
> 7) Go back to [2] or SUCCESS :)
> 
> == BUG-FIX ==
> 1) Write your patch
> 2) Run unit-tests locally
> 3) Write a clear explanation for your patch in the COMMENTS identifying (where
> applicable) any Jira ticket pointing to the issue
> 4) Submit patch to gerrit
> 5) Address any early comments
> 6) Go back to [1] or SUCCESS :)
> > 
> > Chris.
> 
> Cheers,
> Marco
> > 
> > 
> > > -Original Message-
> > > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> > > Behalf Of Dave Barach
> > > Sent: Friday, November 17, 2017 7:45
> > > To: 

Re: [vpp-dev] Please Call DigSafe...

[Marco Varlese]

Hi Chris / Dave,

Few thoughts inline...

On Fri, 2017-11-17 at 13:51 +, Luke, Chris wrote:
> Hi Dave,
> 
> After spending a few minutes to work out that you were talking about a
> proposed patch and not something any of us had merged (and, especially not
> that I merged!), I see that what we need is a balance between not discouraging
> people to experiment, or submit their ideas, but to also steer people towards
> relevant leads before they get in too deep.
> 
> Problem is, if people make huge patches before ever talking to someone, our
> first contact is when they submit it. The teaching moment is when the reviewer
> notices it. That is obviously too late for the first patch, but should help
> with subsequent work.
> 
> This is why open source generally prefers people to keep their patches small
> and thematic; most reviewers tire of seeing many large patches when they are
> developed in isolation and are directionally unsound - to the point that they
> start to see the color bar in the review list and if it's yellow-or-worse, and
> not from someone they specifically associate with quality work, typically
> those submissions end up ignored.
Maybe, a point to consider to come up with a "process" is whether the patch is
addressing existing code (e.g. bug-fix / enhancement) or is a brand-new feature.

I would expect - as you stated - to see small (small to be quantified) patches
to fix a bug in existing code and considerably bigger patches when adding in a
new feature although - sometimes - finding a way to split code into multiple
subsequent patches might be doable. Usually, the impact of a new feature should
be considerably smaller (to existing code path executions) hence a big-fat patch
might be acceptable...

We could use the DRAFT feature in "git review". That is very similar to the RFC
(Request For Comments) method used in other projects. It might be a decent way
to get early feedback and work on the design with key people...
> 
> I don't think we have contribution guidelines for VPP or fd.io in general
> (apart from the style and doc guides); at least a very quick scan of the wiki
> was not fruitful. We should have somewhere to send new people (can we nudge
> people who login to Gerrit for the first time?), and also people whose first
> submission is unacceptable (too big, too complex, directionally unsound). And
> we as reviewers should remain vigilant and, importantly, consistent.
Maybe, we could have a process which starts with a DRAFT-type patch to give time
to core reviewers to understand what's going on.
Beside the patch size topic, another item I would consider is the length/quality
of COMMENTS in the patch; it's pretty common (and not just to FD.io/VPP
projects) to see very brief comments to patches which can make reviewers' life
miserable (and after 2 days that patch-comment would mean nothing even to the
author). IMHO that should be a straight -1...
I am quite a new contributor to VPP but a process I built in my mind over the
past few weeks is split into two sections and looks like:

== NEW FEATURE DEVELOPMENT == 
1) Reach out to core people (Dave / Damjan / Ed / Florin / Dave W / Chris /
etc.) to understand feasibility of the proposed feature;
2) Write your patch (including unit-tests where applicable)
3) Fix coding style (make fixstyle)
4) Check your COMMENTS (do they reflect the code submitted? the longer the
explanation the better)
5) Submit DRAFT patch to gerrit
6) Address any early comments
7) Go back to [2] or SUCCESS :)

== BUG-FIX ==
1) Write your patch
2) Run unit-tests locally
3) Write a clear explanation for your patch in the COMMENTS identifying (where
applicable) any Jira ticket pointing to the issue
4) Submit patch to gerrit
5) Address any early comments
6) Go back to [1] or SUCCESS :)
> 
> Chris.
Cheers,
Marco
> 
> 
> > -Original Message-
> > From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> > Behalf Of Dave Barach
> > Sent: Friday, November 17, 2017 7:45
> > To: vpp-dev@lists.fd.io
> > Subject: [vpp-dev] Please Call DigSafe...
> > 
> > Folks,
> > 
> > At our next project meeting, I'd like to spend a few minutes talking about a
> > good-news / bad-news situation affecting the vpp project.
> > 
> > As the community has expanded, committers have begun noticing
> > unacceptable and unfixable patches in mission-critical code. Yesterday's
> > soap-opera episode involved the ip4/6 speed-paths.
> > 
> > I think we should allocate a bit of meeting time for folks to talk about
> > what
> > they're trying to develop, with an eye towards engaging with relevant area
> > experts from the start.
> > 
> > In most places in the US, folks planning to dig holes on their property are
> > required to call 811 (DigSafe): to avoid hitting buried gas lines and
> > blowing up
> > the neighborhood. It seems like we need to create something
> > similar for the vpp project.
> > 
> > Thoughts?
> > 
> > Thanks... Dave
> > 
> > 

Re: [vpp-dev] Please Call DigSafe...

[Dave Barach (dbarach)]

Dear Chris,

As you probably worked out, the forcing function for my email was a patch that 
both Florin and I -2'ed yesterday; a real stinker.

I want to facilitate discussions of the form: "I'd like to implement X or fix 
Y. What's the right way to do it? Who should I talk to about that?"

Guidelines seem like a good idea. I'll try to write something on the wiki.

Thanks... Dave

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Luke, Chris
Sent: Friday, November 17, 2017 8:51 AM
To: Dave Barach ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Please Call DigSafe...

Hi Dave,

After spending a few minutes to work out that you were talking about a proposed 
patch and not something any of us had merged (and, especially not that I 
merged!), I see that what we need is a balance between not discouraging people 
to experiment, or submit their ideas, but to also steer people towards relevant 
leads before they get in too deep.

Problem is, if people make huge patches before ever talking to someone, our 
first contact is when they submit it. The teaching moment is when the reviewer 
notices it. That is obviously too late for the first patch, but should help 
with subsequent work.

This is why open source generally prefers people to keep their patches small 
and thematic; most reviewers tire of seeing many large patches when they are 
developed in isolation and are directionally unsound - to the point that they 
start to see the color bar in the review list and if it's yellow-or-worse, and 
not from someone they specifically associate with quality work, typically those 
submissions end up ignored.

I don't think we have contribution guidelines for VPP or fd.io in general 
(apart from the style and doc guides); at least a very quick scan of the wiki 
was not fruitful. We should have somewhere to send new people (can we nudge 
people who login to Gerrit for the first time?), and also people whose first 
submission is unacceptable (too big, too complex, directionally unsound). And 
we as reviewers should remain vigilant and, importantly, consistent.

Chris.


> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Dave Barach
> Sent: Friday, November 17, 2017 7:45
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Please Call DigSafe...
> 
> Folks,
> 
> At our next project meeting, I'd like to spend a few minutes talking about a
> good-news / bad-news situation affecting the vpp project.
> 
> As the community has expanded, committers have begun noticing
> unacceptable and unfixable patches in mission-critical code. Yesterday's
> soap-opera episode involved the ip4/6 speed-paths.
> 
> I think we should allocate a bit of meeting time for folks to talk about what
> they're trying to develop, with an eye towards engaging with relevant area
> experts from the start.
> 
> In most places in the US, folks planning to dig holes on their property are
> required to call 811 (DigSafe): to avoid hitting buried gas lines and blowing 
> up
> the neighborhood. It seems like we need to create something
> similar for the vpp project.
> 
> Thoughts?
> 
> Thanks... Dave
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Please Call DigSafe...

[Luke, Chris]

Hi Dave,

After spending a few minutes to work out that you were talking about a proposed 
patch and not something any of us had merged (and, especially not that I 
merged!), I see that what we need is a balance between not discouraging people 
to experiment, or submit their ideas, but to also steer people towards relevant 
leads before they get in too deep.

Problem is, if people make huge patches before ever talking to someone, our 
first contact is when they submit it. The teaching moment is when the reviewer 
notices it. That is obviously too late for the first patch, but should help 
with subsequent work.

This is why open source generally prefers people to keep their patches small 
and thematic; most reviewers tire of seeing many large patches when they are 
developed in isolation and are directionally unsound - to the point that they 
start to see the color bar in the review list and if it's yellow-or-worse, and 
not from someone they specifically associate with quality work, typically those 
submissions end up ignored.

I don't think we have contribution guidelines for VPP or fd.io in general 
(apart from the style and doc guides); at least a very quick scan of the wiki 
was not fruitful. We should have somewhere to send new people (can we nudge 
people who login to Gerrit for the first time?), and also people whose first 
submission is unacceptable (too big, too complex, directionally unsound). And 
we as reviewers should remain vigilant and, importantly, consistent.

Chris.


> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Dave Barach
> Sent: Friday, November 17, 2017 7:45
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Please Call DigSafe...
> 
> Folks,
> 
> At our next project meeting, I'd like to spend a few minutes talking about a
> good-news / bad-news situation affecting the vpp project.
> 
> As the community has expanded, committers have begun noticing
> unacceptable and unfixable patches in mission-critical code. Yesterday's
> soap-opera episode involved the ip4/6 speed-paths.
> 
> I think we should allocate a bit of meeting time for folks to talk about what
> they're trying to develop, with an eye towards engaging with relevant area
> experts from the start.
> 
> In most places in the US, folks planning to dig holes on their property are
> required to call 811 (DigSafe): to avoid hitting buried gas lines and blowing 
> up
> the neighborhood. It seems like we need to create something
> similar for the vpp project.
> 
> Thoughts?
> 
> Thanks... Dave
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Please Call DigSafe...

[Dave Barach]

Folks,

At our next project meeting, I'd like to spend a few minutes talking about a
good-news / bad-news situation affecting the vpp project. 

As the community has expanded, committers have begun noticing unacceptable
and unfixable patches in mission-critical code. Yesterday's soap-opera
episode involved the ip4/6 speed-paths. 

I think we should allocate a bit of meeting time for folks to talk about
what they're trying to develop, with an eye towards engaging with relevant
area experts from the start. 

In most places in the US, folks planning to dig holes on their property are
required to call 811 (DigSafe): to avoid hitting buried gas lines and
blowing up the neighborhood. It seems like we need to create something
similar for the vpp project.

Thoughts?

Thanks... Dave

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] FOSDEM 2018

[Jerome Tollet (jtollet)]

Hi Ole,
I did submit one as well on VPP/networking-vpp for OpenStack integration.
Jerome

Le 17/11/2017 10:25, « vpp-dev-boun...@lists.fd.io au nom de Ole Troan » 
 a écrit :

Ray,

I did submit a loosely defined one on VPP. Anyone else?
Great if we can coordinate a little up front so we don't end up repeating 
ourselves too much.

cheers,
Ole

> On 17 Nov 2017, at 00:19, Kinsella, Ray  wrote:
> 
> Folks,
> 
> The Call for Content for FOSDEM 2018 is closing today!
> The "SDN and NFV room" at FOSDEM is great way to get the FD.io message 
out there.
> 
> Last minute submissions would be most welcome!
> To submit see,
> 
> 
https://blogs.gnome.org/bolsh/2017/11/01/fosdem-2018-sdnnfv-devroom-call-for-content/
> 
> Thanks,
> 
> Ray K
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev



___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Flowprobe Question

[Ole Troan]

Johan,

Can you include configuration and output from show trace? (For when you are 
sending ICMP and TCP.)

Best regards,
Ole

> On 16 Nov 2017, at 23:20, MUEDSAM, JOHAN  wrote:
> 
> Thanks Ole, got it working after running the tests and digging through the 
> test code. I'm able to capture and parse the IPFIX output from the Flowprobe 
> plugin.
> 
> I have another question. I'm going through the examples, specifically the 
> "Progressive Tutorial - Source NAT" and "VPP/Configure VPP As A Router 
> Between Namespaces".
> 
> I get the examples working as is, however they only allow ICMP traffic 
> through, TCP and UDP gets dropped somewhere and can't get through.
> 
> Do I need to change the setup to get TCP/UDP to go through?
> 
> /Johan
> 
> On 11/13/17, 10:53 AM, "Ole Troan"  wrote:
> 
>Hi Johan,
> 
>You have a route to 192.168.65.2?
>Nothing shows up in "show error"?
> 
>You can look at test/test_flowprobe.py
>for examples. And you might also try a make test TEST=flowprobe to ensure 
> your build works.
> 
>On second pass on your configuration.
>You have enabled flow collection in the L2 path, if you are IP forwarding 
> you need to enable it in the L3 path.
>> vppctl flowprobe feature add-del host-vpp1out l3
> 
>Cheers,
>Ole
> 
> 
>> On 14 Nov 2017, at 00:38, MUEDSAM, JOHAN  wrote:
>> 
>> Hi,
>> 
>> I'm trying to capture IPFIX records of traffic on my VPP managed interfaces. 
>> So far I haven't been able to see any templates or IPFIX records in my 
>> collector.
>> 
>> Here's my VPP setup (from the progressive tutorial), I'm using a docker 
>> container with Ubuntu 16.04 and the binary VPP master release:
>> ip link add name vpp1out type veth peer name vpp1host
>> ip link set dev vpp1out up
>> ip link set dev vpp1host up
>> ip addr add 10.10.1.1/24 dev vpp1host
>> ip addr show vpp1host
>> vppctl create host-interface name vpp1out
>> vppctl show hardware
>> vppctl set int state host-vpp1out up
>> vppctl show int
>> vppctl set int ip address host-vpp1out 10.10.1.2/24
>> vppctl show int addr
>> 
>> Flowprobe setup, here I'm using non VPP managed IPs to setup source and 
>> collector addresses:
>> vppctl flowprobe params record l2 l3 l4 active 20 passive 120
>> vppctl flowprobe feature add-del host-vpp1out l2
>> vppctl set ipfix exporter collector 192.168.65.2 src 192.168.65.2 
>> template-interval 20 port 4739 path-mtu 1450
>> 
>> I generate traffic by pinging the 10.10.1.2 address above.
>> And I'm currently listening on the collector UDP port using this to detect 
>> IPFIX data coming from VPP: nc -l -u 192.168.65.2 -p 4739
>> I can see traffic in the Flowprobe table but as I mentioned I get nothing on 
>> the UDP collector interface.
>> 
>> Any ideas of why I'm not seeing any IPFIX data (not even templates) on the 
>> UDP port?
>> Is there a working e2e example of how to use Flowprobe I could start with?
>> 
>> Any pointers would be greatly appreciated.
>> 
>> Thanks,
>> Johan
>> 
>> ___
>> vpp-dev mailing list
>> vpp-dev@lists.fd.io
>> https://lists.fd.io/mailman/listinfo/vpp-dev
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] FOSDEM 2018

[Ole Troan]

Ray,

I did submit a loosely defined one on VPP. Anyone else?
Great if we can coordinate a little up front so we don't end up repeating 
ourselves too much.

cheers,
Ole

> On 17 Nov 2017, at 00:19, Kinsella, Ray  wrote:
> 
> Folks,
> 
> The Call for Content for FOSDEM 2018 is closing today!
> The "SDN and NFV room" at FOSDEM is great way to get the FD.io message out 
> there.
> 
> Last minute submissions would be most welcome!
> To submit see,
> 
> https://blogs.gnome.org/bolsh/2017/11/01/fosdem-2018-sdnnfv-devroom-call-for-content/
> 
> Thanks,
> 
> Ray K
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev



signature.asc
Description: Message signed with OpenPGP
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev