2016-03-02 11:28 GMT+01:00 Ondrej Lichtner <olichtne@redhat.com>:
On Sat, Feb 27, 2016 at 11:59:26AM +0100, Jiri Pirko wrote:
> Thu, Feb 25, 2016 at 11:46:51AM CET, jprochaz@redhat.com wrote:
> >
> >Summary
> >=======
> >Drafts above are not meant to be final, it sure can be improved and
> >modified to satisfy our needs. But we need to come to conclusion for both
> >Mlx and RH side, so I can start working on it.
> >
> >Some important questions regarding PyRecipes:
> >---------------------------------------------
> >I. Soft interfaces - in setup phase and task phase or only in task phase?
>
> As I wrote above, only in task. It is completely pointless to do it in
> setup phase.

I want the option of both... I disagree that it would be hard to
implement and that it would be confusing... you're already going to have
functions that work only in one half of the recipe and don't make sense
in the other part - running commands before match. These checks are
basicaly the same thing.

HOWEVER, I want this to finally get going and arguing about what
is/isn't confusing is pointless so... I will accept the "just in task"
option, for now... if I will need/want soft ifaces before the match I'll
just add this functionality myself...

​Acknowledged.​
 

>
>
> >II. Portability - one task == one recipe, or allow combinations of networks
> >with different tasks?
>
> One task=one recipe. You can easily use some lib that will do the common
> things for you. Exactly as we do it in switchdev recipes. It's a python,
> the task here is just an entry point. You can do whatever from that.

As long as you're purely in python you should be able to do as much
portability as you want, it just depends on the workflow you choose...
Which is why I've been saying that the user should have as much options
as possible...

>
>
> >III. Should task be generic or specific?
>
> As I wrote above, you can easily split this in:
> 1 specific wrapper
> 2 lib methods - called by specific wrapper
>
>
> >IV. Do we have to get rid of IDs?
>
> YES! No reason for them what so ever.

yes, no IDs PLEASE... we have objects, let's use them... The issue of
logging can be solved through variable names and informing the user of
the mapping at the start of the recipe - we already do this so no change
there...
 
​We could​
 
​ keep IDs as optional param for host, the ID then will be used
in logging. If no ID is entered, use variable name.​


>
>
> >
> >My opinion on the matter
> >========================
> >Favourite approach - #3
> >
> >Answers to questions:
> >---------------------
> >I. Soft interfaces - only in task phase - to follow 1 task == 1 recipe
> >mentality, will bring easier maintaining
> >II. Portability - one task == one recipe - even our use case shows, that
> >tests don't allow so much combination (1 task is being used in avg. 1-2
> >recipes in phase1, 2-3 recipes in phase2), so I don't thinks its so
> >important to use to preserve it
> >III. Specific task - generic stuff can be defined by a new layer of
> >abstraction, like TestLib in switchdev tests
> >IV. I do not think IDs are such evil that we should get rid of it, altough
> >I agree  object oriented approach (which we want to follow, thus PyRecipes
> >became a thing in the first place) should be only using instances of
> >objects in both task and setup.
>
> So I think that according to your answers, it looks like you like approach #1
> the most. It's exactly that. With one expection that that is you would
> preserve the ids. I don't understand why. Nodoby will care about them.
> Inside the lnst implementation, they can stay, but they should not get
> into python api.

In the implementation they'll have to stay, for now, because of how the
matching algorithm is implemented... But I believe we'll be able to get
rid of them completely eventually...

Overall, nice summary. In the end, I think the end goal is to have as
generic an approach as possible (with a recommended way of doing
things). But for now... let's just do the recommended way (jpirko's
approach) of doing things and work on the rest later.

-Ondrej


​Thanks everyone for their replies and comments. Looks like
#1 approach it is, which may be extended in the future based
on our needs.

I'll start working on the implementation right away and once I'll
know, I'll let you know when the patches will be ready for testing.

Thanks again everyone,
Jiri Prochazka