[jira] [Created] (MESOS-7702) Fix the validation / conversion strategy of `Resources`.

["Michael Park (JIRA)" <ji...@apache.org>]

Michael Park created MESOS-7702:
-----------------------------------

             Summary: Fix the validation / conversion strategy of `Resources`.
                 Key: MESOS-7702
                 URL: https://issues.apache.org/jira/browse/MESOS-7702
             Project: Mesos
          Issue Type: Bug
            Reporter: Michael Park


With reservation refinement, we introduced the "post-reservation-refinement" format which uses a new {{Resource.reservations}} field to represent the reservation state of a resource. The "pre-reservation-refinement" format used the {{Resource.role}} and {{Resource.reservation}}.

In order to avoid writing two code paths for everything in every component, the general strategy is to convert the resource format at the component boundaries. That is, convert to the "post-reservation-refinement" format in-bound, and convert back as necessary out-bound.

While I think this strategy is still good, the mechanism of how this happens really needs to change.
It's very hard to tell and keep track of the state of {{Resource}} objects and at what point they've been validated and have been converted.

For example, can we afford to call {{convertResourceFormat}} *after* {{validation::operation::validate}}? Since {{operation::validate}} calls {{Resources::validate}} within it, it may seem innocent to convert after the operation has been validated. The issue though is that after {{Resources::validate}} has been called within {{operation::validate}}, it starts to use functions that require resources to be validated, and in the "post-reservation-refinement" format. What this means is that validation and conversion has a much tighter relationship than is enforced currently.

Besides the complexity that I added during reservation refinement, I also believe that we already have some tech-debt in this area. For example, the {{Resources}} constructor simply __drops__ invalid resources. This is really subtle, and would be a nightmare to track down. I think a better approach would be to have a creation function that can fail correctly. Since we live in a world with no exceptions, this can be solved by having a creation function that returns a {{Try}}. That is, {{Try<Resources> createResources(...);}} would do the validation and return an {{Error}} on failure. Note that we can also bundle the __conversion__ logic here as well.

* https://reviews.apache.org/r/60253/



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)