> 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 > >
