Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-03-13 Thread Greg Mann 


> On March 9, 2018, 10:16 p.m., Greg Mann wrote:
> > src/common/http.hpp
> > Lines 198 (patched)
> > 
> >
> > See the comment I left on https://reviews.apache.org/r/65313/ - I 
> > wonder if `action` really needs to be a template parameter here?
> 
> Alexander Rojas wrote:
> Strictly speaking it doesn't need to be a template, but then overrides 
> like:
> 
> ```c++
> template <>
> inline bool ObjectApprovers::approved(
> const Resource& resource)
> {
>   // ...
> }
> ```
> 
> Would have need to be dispatched to helper functions or handler in big 
> ifs in `approved()`.
> 
> The end result would be, you just move the part hard to read from one 
> side to the next.
> 
> My personal opinion is that the helper in the agent cleanup is more 
> readable an a better price to pay than a gigantic switch here.

As we discussed in chat, we can clean up the callsites in the agent a bit by 
duplicating code if we want. Let's leave this as-is right now.


- Greg


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/#review198973
---


On March 8, 2018, 12:14 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65311/
> ---
> 
> (Updated March 8, 2018, 12:14 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Greg Mann.
> 
> 
> Bugs: MESOS-8434
> https://issues.apache.org/jira/browse/MESOS-8434
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Introduces the class `ObjectApprovers` which unifies the different
> mechanisms used in Mesos in order to perform authorization.
> 
> This new class will supersede the `Acceptor` interfaces and their
> logic.
> 
> Follow up patches will make use of this interface and remove
> deprecated code.
> 
> 
> Diffs
> -
> 
>   src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
>   src/common/http.cpp 8d3a4ad63bd74e0313082bad3d89c21fbf54f256 
> 
> 
> Diff: https://reviews.apache.org/r/65311/diff/6/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-03-12 Thread Alexander Rojas 


> On March 9, 2018, 11:16 p.m., Greg Mann wrote:
> > src/common/http.hpp
> > Lines 198 (patched)
> > 
> >
> > See the comment I left on https://reviews.apache.org/r/65313/ - I 
> > wonder if `action` really needs to be a template parameter here?

Strictly speaking it doesn't need to be a template, but then overrides like:

```c++
template <>
inline bool ObjectApprovers::approved(
const Resource& resource)
{
  // ...
}
```

Would have need to be dispatched to helper functions or handler in big ifs in 
`approved()`.

The end result would be, you just move the part hard to read from one side to 
the next.

My personal opinion is that the helper in the agent cleanup is more readable an 
a better price to pay than a gigantic switch here.


- Alexander


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/#review198973
---


On March 8, 2018, 1:14 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65311/
> ---
> 
> (Updated March 8, 2018, 1:14 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Greg Mann.
> 
> 
> Bugs: MESOS-8434
> https://issues.apache.org/jira/browse/MESOS-8434
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Introduces the class `ObjectApprovers` which unifies the different
> mechanisms used in Mesos in order to perform authorization.
> 
> This new class will supersede the `Acceptor` interfaces and their
> logic.
> 
> Follow up patches will make use of this interface and remove
> deprecated code.
> 
> 
> Diffs
> -
> 
>   src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
>   src/common/http.cpp 8d3a4ad63bd74e0313082bad3d89c21fbf54f256 
> 
> 
> Diff: https://reviews.apache.org/r/65311/diff/6/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-03-09 Thread Greg Mann 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/#review198973
---




src/common/http.hpp
Lines 198 (patched)


See the comment I left on https://reviews.apache.org/r/65313/ - I wonder if 
`action` really needs to be a template parameter here?


- Greg Mann


On March 8, 2018, 12:14 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65311/
> ---
> 
> (Updated March 8, 2018, 12:14 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Greg Mann.
> 
> 
> Bugs: MESOS-8434
> https://issues.apache.org/jira/browse/MESOS-8434
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Introduces the class `ObjectApprovers` which unifies the different
> mechanisms used in Mesos in order to perform authorization.
> 
> This new class will supersede the `Acceptor` interfaces and their
> logic.
> 
> Follow up patches will make use of this interface and remove
> deprecated code.
> 
> 
> Diffs
> -
> 
>   src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
>   src/common/http.cpp 8d3a4ad63bd74e0313082bad3d89c21fbf54f256 
> 
> 
> Diff: https://reviews.apache.org/r/65311/diff/6/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-03-09 Thread Greg Mann 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/#review198970
---


Ship it!




Ship It!

- Greg Mann


On March 8, 2018, 12:14 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65311/
> ---
> 
> (Updated March 8, 2018, 12:14 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Greg Mann.
> 
> 
> Bugs: MESOS-8434
> https://issues.apache.org/jira/browse/MESOS-8434
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Introduces the class `ObjectApprovers` which unifies the different
> mechanisms used in Mesos in order to perform authorization.
> 
> This new class will supersede the `Acceptor` interfaces and their
> logic.
> 
> Follow up patches will make use of this interface and remove
> deprecated code.
> 
> 
> Diffs
> -
> 
>   src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
>   src/common/http.cpp 8d3a4ad63bd74e0313082bad3d89c21fbf54f256 
> 
> 
> Diff: https://reviews.apache.org/r/65311/diff/6/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-03-08 Thread Alexander Rojas 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/
---

(Updated March 8, 2018, 1:14 p.m.)


Review request for mesos, Benjamin Hindman and Greg Mann.


Bugs: MESOS-8434
https://issues.apache.org/jira/browse/MESOS-8434


Repository: mesos


Description
---

Introduces the class `ObjectApprovers` which unifies the different
mechanisms used in Mesos in order to perform authorization.

This new class will supersede the `Acceptor` interfaces and their
logic.

Follow up patches will make use of this interface and remove
deprecated code.


Diffs (updated)
-

  src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
  src/common/http.cpp 8d3a4ad63bd74e0313082bad3d89c21fbf54f256 


Diff: https://reviews.apache.org/r/65311/diff/6/

Changes: https://reviews.apache.org/r/65311/diff/5-6/


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-03-08 Thread Alexander Rojas 


> On March 8, 2018, 5:24 a.m., Greg Mann wrote:
> > src/common/http.hpp
> > Lines 244 (patched)
> > 
> >
> > Could you verify that this is true in the case of 
> > resource-provider-capable agents? See 
> > https://github.com/apache/mesos/blob/66bae088de61ae0cc3f9c5fac6f4b6f9695a27d1/src/master/master.cpp#L7087-L7117
> > 
> > I haven't yet identified code in the agent which downgrades resources 
> > before checkpointing.

The code was introduced in [r/61171/](https://reviews.apache.org/r/61171/) and 
we discussed that thoroughly there. However, removing this if doesn't seem to 
cause any change in the tests so now I am wondering whether we need it at all.

I think the best course of action is to keep it and investigate further whether 
it is necessary.


- Alexander


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/#review198811
---


On Feb. 5, 2018, 2:52 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65311/
> ---
> 
> (Updated Feb. 5, 2018, 2:52 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Greg Mann.
> 
> 
> Bugs: MESOS-8434
> https://issues.apache.org/jira/browse/MESOS-8434
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Introduces the class `ObjectApprovers` which unifies the different
> mechanisms used in Mesos in order to perform authorization.
> 
> This new class will supersede the `Acceptor` interfaces and their
> logic.
> 
> Follow up patches will make use of this interface and remove
> deprecated code.
> 
> 
> Diffs
> -
> 
>   src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
>   src/common/http.cpp 8d3a4ad63bd74e0313082bad3d89c21fbf54f256 
> 
> 
> Diff: https://reviews.apache.org/r/65311/diff/5/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-03-07 Thread Greg Mann 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/#review198811
---




src/common/http.hpp
Lines 215-220 (patched)


Looks like we'll end up logging an extra space when `principal.isNone()`.



src/common/http.hpp
Lines 244 (patched)


Could you verify that this is true in the case of resource-provider-capable 
agents? See 
https://github.com/apache/mesos/blob/66bae088de61ae0cc3f9c5fac6f4b6f9695a27d1/src/master/master.cpp#L7087-L7117

I haven't yet identified code in the agent which downgrades resources 
before checkpointing.



src/common/http.cpp
Lines 874 (patched)


Indented too far.



src/common/http.cpp
Lines 894 (patched)


Should we use an underscore for this `approvers` variable?


- Greg Mann


On Feb. 5, 2018, 1:52 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65311/
> ---
> 
> (Updated Feb. 5, 2018, 1:52 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Greg Mann.
> 
> 
> Bugs: MESOS-8434
> https://issues.apache.org/jira/browse/MESOS-8434
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Introduces the class `ObjectApprovers` which unifies the different
> mechanisms used in Mesos in order to perform authorization.
> 
> This new class will supersede the `Acceptor` interfaces and their
> logic.
> 
> Follow up patches will make use of this interface and remove
> deprecated code.
> 
> 
> Diffs
> -
> 
>   src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
>   src/common/http.cpp 8d3a4ad63bd74e0313082bad3d89c21fbf54f256 
> 
> 
> Diff: https://reviews.apache.org/r/65311/diff/5/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-02-05 Thread Alexander Rojas 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/
---

(Updated Feb. 5, 2018, 2:52 p.m.)


Review request for mesos, Benjamin Hindman and Greg Mann.


Bugs: MESOS-8434
https://issues.apache.org/jira/browse/MESOS-8434


Repository: mesos


Description
---

Introduces the class `ObjectApprovers` which unifies the different
mechanisms used in Mesos in order to perform authorization.

This new class will supersede the `Acceptor` interfaces and their
logic.

Follow up patches will make use of this interface and remove
deprecated code.


Diffs (updated)
-

  src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
  src/common/http.cpp 728fc554917ed031f9cb3d811fbbc064307b3e32 


Diff: https://reviews.apache.org/r/65311/diff/4/

Changes: https://reviews.apache.org/r/65311/diff/3-4/


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-02-05 Thread Alexander Rojas 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/
---

(Updated Feb. 5, 2018, 11:57 a.m.)


Review request for mesos, Benjamin Hindman and Greg Mann.


Bugs: MESOS-8434
https://issues.apache.org/jira/browse/MESOS-8434


Repository: mesos


Description
---

Introduces the class `ObjectApprovers` which unifies the different
mechanisms used in Mesos in order to perform authorization.

This new class will supersede the `Acceptor` interfaces and their
logic.

Follow up patches will make use of this interface and remove
deprecated code.


Diffs (updated)
-

  src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
  src/common/http.cpp 728fc554917ed031f9cb3d811fbbc064307b3e32 


Diff: https://reviews.apache.org/r/65311/diff/3/

Changes: https://reviews.apache.org/r/65311/diff/2-3/


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-02-02 Thread Alexander Rojas 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/
---

(Updated Feb. 2, 2018, 4:01 p.m.)


Review request for mesos, Benjamin Hindman and Greg Mann.


Bugs: MESOS-8434
https://issues.apache.org/jira/browse/MESOS-8434


Repository: mesos


Description
---

Introduces the class `ObjectApprovers` which unifies the different
mechanisms used in Mesos in order to perform authorization.

This new class will supersede the `Acceptor` interfaces and their
logic.

Follow up patches will make use of this interface and remove
deprecated code.


Diffs (updated)
-

  src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
  src/common/http.cpp 728fc554917ed031f9cb3d811fbbc064307b3e32 


Diff: https://reviews.apache.org/r/65311/diff/2/

Changes: https://reviews.apache.org/r/65311/diff/1-2/


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-02-02 Thread Alexander Rojas 


> On Jan. 26, 2018, 5:01 a.m., Greg Mann wrote:
> > src/common/http.hpp
> > Lines 57 (patched)
> > 
> >
> > Is this case needed for type deduction? clang seems to build this code 
> > fine without it.

>From the research I did, not getting the underlying type of an enum just 
>defaults to int. I think this was done by benh in our effort to move towards 
>class enums, so I would prefer to keep this one.


> On Jan. 26, 2018, 5:01 a.m., Greg Mann wrote:
> > src/common/http.cpp
> > Lines 870 (patched)
> > 
> >
> > This seems like very simple validation to do. I would suggest if we 
> > want to ensure this, let's just do it now and remove the TODO?
> > 
> > Should it be a CHECK?

I just add everything to a set which will remove duplicates. Not sure if having 
them even demands a log line.


> On Jan. 26, 2018, 5:01 a.m., Greg Mann wrote:
> > src/common/http.cpp
> > Lines 875-887 (patched)
> > 
> >
> > Since this is a pretty hot code path, should we consider optimizations 
> > now?
> > 
> > Since the authorizer is not SOME or NONE on a per-action basis, we 
> > could have an `AcceptingObjectApprovers` which we return immediately if 
> > there is no authorizer:
> > 
> > ```
> > if (authorizer.isNone()) {
> >   return Owned(
> >   new AcceptingObjectApprovers());
> > } else {
> >   return process::collect( etc...
> > ```
> > 
> > WDYT?

I agree that it makes no sense to waste time creating `ObjectApprover` 
instances which will be accepting ones, I just figured out it can be done 
before and faster.


> On Jan. 26, 2018, 5:01 a.m., Greg Mann wrote:
> > src/common/http.cpp
> > Lines 1057-1059 (patched)
> > 
> >
> > Instead of a free function helper, what do you think about adding a 
> > specialization/overload to handle resources with the VIEW_ROLE action, like:
> > ```
> > template <>
> > bool ObjectApprovers::approved(
> > const Resource& resource)
> > {
> >   // Necessary because recovered agents are presented in old format.
> >   if (resource.has_role() && resource.role() != "*" &&
> >   !approved(resource.role())) {
> > return false;
> >   }
> > 
> >   // Reservations follow a path model where each entry is a child of the
> >   // previous one. Therefore, to accept the resource the acceptor has to
> >   // accept all entries.
> >   foreach (Resource::ReservationInfo reservation, 
> > resource.reservations()) {
> > if (!approved(reservation.role())) {
> >   return false;
> > }
> >   }
> > 
> >   if (resource.has_allocation_info() &&
> >   !approved(
> >   resource.allocation_info().role())) {
> > return false;
> >   }
> > 
> >   return true;
> > }
> > ```
> > 
> > And then the callsites could look like:
> > ```
> > approvers->approved(resource);
> > ```
> > 
> > WDYT?

I liked the idea but somehow the program didn't resolved the templates 
correctly. I would leave it like this initially, and I will try to figure out 
the right way of doing it. If you're ok with it.


- Alexander


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/#review196303
---


On Jan. 24, 2018, 6:30 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65311/
> ---
> 
> (Updated Jan. 24, 2018, 6:30 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Greg Mann.
> 
> 
> Bugs: MESOS-8434
> https://issues.apache.org/jira/browse/MESOS-8434
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Introduces the class `ObjectApprovers` which unifies the different
> mechanisms used in Mesos in order to perform authorization.
> 
> This new class will supersede the `Acceptor` interfaces and their
> logic.
> 
> Follow up patches will make use of this interface and remove
> deprecated code.
> 
> 
> Diffs
> -
> 
>   src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
>   src/common/http.cpp 728fc554917ed031f9cb3d811fbbc064307b3e32 
> 
> 
> Diff: https://reviews.apache.org/r/65311/diff/1/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>

Re: Review Request 65311: Added the ObjectApprovers to which unifies authorization logic.

2018-01-25 Thread Greg Mann 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/65311/#review196303
---




src/common/http.hpp
Lines 38-39 (original), 39-44 (patched)


Nit: I think just one newline here? And below, at the end of the namespace.



src/common/http.hpp
Lines 57 (patched)


Is this case needed for type deduction? clang seems to build this code fine 
without it.



src/common/http.hpp
Lines 166 (patched)


Nit: I think there should be just one newline here?



src/common/http.hpp
Lines 209 (patched)


Suggestion: s/UNEXPECTED/unexpected/



src/common/http.hpp
Lines 231 (patched)


Indented too far.



src/common/http.hpp
Lines 232-233 (patched)


I would probably do:

```
hashmap<
  authorization::Action,
  process::Owned>&& _approvers,
```

up to you



src/common/http.hpp
Lines 282-283 (original), 357-359 (patched)


One more newline here?



src/common/http.cpp
Lines 870 (patched)


This seems like very simple validation to do. I would suggest if we want to 
ensure this, let's just do it now and remove the TODO?

Should it be a CHECK?



src/common/http.cpp
Lines 875-887 (patched)


Since this is a pretty hot code path, should we consider optimizations now?

Since the authorizer is not SOME or NONE on a per-action basis, we could 
have an `AcceptingObjectApprovers` which we return immediately if there is no 
authorizer:

```
if (authorizer.isNone()) {
  return Owned(
  new AcceptingObjectApprovers());
} else {
  return process::collect( etc...
```

WDYT?



src/common/http.cpp
Lines 1057-1059 (patched)


Instead of a free function helper, what do you think about adding a 
specialization/overload to handle resources with the VIEW_ROLE action, like:
```
template <>
bool ObjectApprovers::approved(
const Resource& resource)
{
  // Necessary because recovered agents are presented in old format.
  if (resource.has_role() && resource.role() != "*" &&
  !approved(resource.role())) {
return false;
  }

  // Reservations follow a path model where each entry is a child of the
  // previous one. Therefore, to accept the resource the acceptor has to
  // accept all entries.
  foreach (Resource::ReservationInfo reservation, resource.reservations()) {
if (!approved(reservation.role())) {
  return false;
}
  }

  if (resource.has_allocation_info() &&
  !approved(
  resource.allocation_info().role())) {
return false;
  }

  return true;
}
```

And then the callsites could look like:
```
approvers->approved(resource);
```

WDYT?



src/common/http.cpp
Lines 1071-1075 (patched)


Suggestion: could you move this conditional to the end? Then the two 
reservation-related blocks will be adjacent.


- Greg Mann


On Jan. 24, 2018, 5:30 p.m., Alexander Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65311/
> ---
> 
> (Updated Jan. 24, 2018, 5:30 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Greg Mann.
> 
> 
> Bugs: MESOS-8434
> https://issues.apache.org/jira/browse/MESOS-8434
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Introduces the class `ObjectApprovers` which unifies the different
> mechanisms used in Mesos in order to perform authorization.
> 
> This new class will supersede the `Acceptor` interfaces and their
> logic.
> 
> Follow up patches will make use of this interface and remove
> deprecated code.
> 
> 
> Diffs
> -
> 
>   src/common/http.hpp 750d3bfba1647624983108bdd23295a3b3091fe4 
>   src/common/http.cpp 728fc554917ed031f9cb3d811fbbc064307b3e32 
> 
> 
> Diff: https://reviews.apache.org/r/65311/diff/1/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Alexander Rojas
> 
>