mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam B" <a...@mesosphere.io>
Subject Re: Review Request 29274: Added Resource::Transformation to mesos.proto.
Date Tue, 06 Jan 2015 06:09:50 GMT


> On Dec. 23, 2014, 4:45 p.m., Adam B wrote:
> > include/mesos/mesos.proto, lines 436-437
> > <https://reviews.apache.org/r/29274/diff/1/?file=797605#file797605line436>
> >
> >     So, `Resource` contains an `Operation` which contains repeated `Resource`s?
But there is no actual Operation field on Resource.
> >     Looks like ACL is currently the only message that has submessages that aren't
used by fields of the parent message.
> >     Perhaps Operation should be a top-level message instead?
> >     What about Operations on things besides resources?
> 
> Jie Yu wrote:
>     'Operation' (or 'Transformation') to me is a Resource specific stuff. Putting that
in the top level is too vague to me. Maybe we should call it ResourcesTransformation on the
top level. What do you think. (But I still prefer putting that nested inside Resource).

Protobuf's not the most expressive language. Maybe just a comment above Transformation that
it is nested inside Resource for namespacing reasons (rather than encapsulation reasons).
Unless somebody knows of a better way in protobufs.
We could potentially have other Transformation messages (e.g. transform my FrameworkInfo from
`current` to `desired`), but we can also nest/namespace each of those into the messages they
transform.


> On Dec. 23, 2014, 4:45 p.m., Adam B wrote:
> > include/mesos/mesos.proto, lines 435-437
> > <https://reviews.apache.org/r/29274/diff/1/?file=797605#file797605line435>
> >
> >     Is there going to have to be complex verification? What happens if I specify
a non-disk resource in before but not after, for a disk-related operation? What if a `before`
resource doesn't actually exist?
> >     A declarative approach where one only specifies (an action and) the desired
outcome would allow the recipient (master) to do whatever is necessary to reach the desired
outcome.
> 
> Jie Yu wrote:
>     My worry about specifying only the desired outcome is that sometimes it's ambiguate
(master has multiple ways to perform the transformation). I think it's the framework who is
ultimately responsible for deciding what transformation should be performed, not master. Therefore,
I still prefer the 'current/desired' model more because the framework can clearly convey its
transforamtion decision.
>     
>     What do you think? I would like to hear comments from others as well.
> 
> Jie Yu wrote:
>     One more example. If you only specify the desired outcome, how do you specify the
release of a persistent disk? The master does not know which persistent disk the framework
wants to release if we don't specify the 'current'.
> 
> Michael Park wrote:
>     I thought about this as well and we definitely need both `current`/`desired`. We
don't always know which `current` we want transformed into `desired`. The release of a persistent
disk is a great example for this, another example is once we add revocable resources, we can
no longer assume that the `current` will consist of only unreserved resources.

Agreed. We need both current and desired (and Type for explicitness).

And there will have to be verification, but I doubt it's that complex.
1. Verify that the current resource actually exists in the offer/running-task.
2. Check the Tranformation::Type to see what fields and resource types are expected.
3. Verify that the resource is of a valid type (e.g. disk for persistent disk).
4. Verify that the modified fields represent a valid transition.
5. Verify that no unrelated fields have changed.


> On Dec. 23, 2014, 4:45 p.m., Adam B wrote:
> > include/mesos/mesos.proto, line 429
> > <https://reviews.apache.org/r/29274/diff/1/?file=797605#file797605line429>
> >
> >     s/Operation/Action/?
> >     Or `Transformation` like you had before?
> 
> Jie Yu wrote:
>     Yeah, I originally propose the name `Transformation`. I think BenM liked the name
Operation more since 'acquireXXX'/'releaseXXX' are like "operations". BenM, what do you think
if I change it back to Transformation and kill the C++ Resoures::Transformation in favor of
this protobuf?

No big deal to me. I just like to discuss alternatives. :)


- Adam


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


On Jan. 5, 2015, 12:17 p.m., Jie Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/29274/
> -----------------------------------------------------------
> 
> (Updated Jan. 5, 2015, 12:17 p.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, switched to 'mcypark',
and Vinod Kone.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Added Resource::Transformation to mesos.proto per our discussion in https://reviews.apache.org/r/29173/
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto 540071db64961466eb75c779b3ea6863f4594437 
> 
> Diff: https://reviews.apache.org/r/29274/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message