mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Mann <g...@mesosphere.io>
Subject Re: Review Request 63001: Updated protobuf definitions related to offer operations.
Date Thu, 26 Oct 2017 22:49:38 GMT

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




include/mesos/mesos.proto
Lines 2157 (patched)
<https://reviews.apache.org/r/63001/#comment266369>

    s/status/statuses/



include/mesos/mesos.proto
Lines 2157-2158 (patched)
<https://reviews.apache.org/r/63001/#comment266370>

    Can we clarify here that this is an ordered list?



include/mesos/mesos.proto
Lines 2162 (patched)
<https://reviews.apache.org/r/63001/#comment266372>

    s/framework specified/framework-specified/
    
    s/id/ID/ ??
    
    Here and below.



include/mesos/mesos.proto
Lines 2204 (patched)
<https://reviews.apache.org/r/63001/#comment266394>

    Backticks instead of quotes here for consistency.



include/mesos/resource_provider/resource_provider.proto
Line 66 (original), 72 (patched)
<https://reviews.apache.org/r/63001/#comment266396>

    Do you want to use `OFFER_OPERATION` here instead? Or, do you think it's OK to just use
`OPERATION` since this is within the RP? Here and elsewhere.



include/mesos/v1/mesos.proto
Lines 2145 (patched)
<https://reviews.apache.org/r/63001/#comment266392>

    I'm a little bit concerned that the names of the various IDs in this RR will become confusing
for devs. We have:
    1) `OfferOperationID`, with a field name of `operation_id`
    2) `bytes uuid`, with a field name of `uuid` (this is the status update ID)
    3) `bytes uuid`, with a field name of `operation_uuid` (this is our internal ID for the
operation)
    
    What would you think about naming the fields `operation_id`, `operation_update_uuid`,
and `operation_internal_uuid`, respectively? (could also just do `update_uuid` and `internal_uuid`
for the latter two)
    
    Since the fields are in different messages, I'm not sure how bad this would really be,
just a thought. Let me know what you think.



include/mesos/v1/mesos.proto
Lines 2185 (patched)
<https://reviews.apache.org/r/63001/#comment266393>

    Backticks instead of quotes here for consistency.



src/messages/messages.proto
Lines 608-610 (original), 608-610 (patched)
<https://reviews.apache.org/r/63001/#comment266402>

    Add a note about offer operations here?



src/messages/messages.proto
Lines 638 (patched)
<https://reviews.apache.org/r/63001/#comment266401>

    s/update/updates/


- Greg Mann


On Oct. 19, 2017, 12:08 a.m., Jie Yu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63001/
> -----------------------------------------------------------
> 
> (Updated Oct. 19, 2017, 12:08 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Benjamin Mahler, Gaston Kleiman, Greg Mann,
Jan Schlicht, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Updated protobuf definitions related to offer operations.
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto 859fdff4d9a0604bc506b08af79075084ae23466 
>   include/mesos/resource_provider/resource_provider.proto f5a9073075327019fd133bd51265f695ef464845

>   include/mesos/v1/mesos.proto cfd4abd3af1d8c9fbd31659161eada9ec9f92282 
>   include/mesos/v1/resource_provider/resource_provider.proto e5cbede5b6e57a8641fca1ebfee5454f292cc24c

>   src/messages/messages.proto 0a32b3457e9143a7d48670610ca3e56dd516136f 
>   src/resource_provider/manager.cpp 31fcb789f5ab907511e868c374c49f7457a33ed3 
>   src/resource_provider/validation.cpp d2927227f60ab0d4ae2481ad73a31ee444b48ee0 
>   src/tests/resource_provider_validation_tests.cpp f182bff4670318e9de22c2915c5dbb423a74ad6c

> 
> 
> Diff: https://reviews.apache.org/r/63001/diff/9/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Jie Yu
> 
>


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