[jira] [Commented] (MESOS-5642) Move include/mesos/v1/master/allocator.proto to its own directory and package

2016-06-22 Thread Vinod Kone (JIRA)

[ 
https://issues.apache.org/jira/browse/MESOS-5642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15345006#comment-15345006
 ] 

Vinod Kone commented on MESOS-5642:
---

I don't know of any modules for allocator. But it is best to send an email to 
the dev list about this change and see if someone objects. cc [~karya]

Also currently modules have to be recompiled for every version of mesos, so it 
might not be that big of a problem. For example, we completely changed the 
authorizer interface between 0.28.0 and 1.0.  

> Move include/mesos/v1/master/allocator.proto to its own directory and package
> -
>
> Key: MESOS-5642
> URL: https://issues.apache.org/jira/browse/MESOS-5642
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API
>Reporter: Zhitao Li
>Assignee: Zhitao Li
> Fix For: 1.0.0
>
>
> Right now, all protobuf used in `include/mesos/v1` is in their own directory 
> and package except for allocator.
> We should do the same for it for both consistency, as well as protobuf 
> compiler friendliness (e.g. golang compiler doesn't work well when two .proto 
> files generates messages into same package).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MESOS-5642) Move include/mesos/v1/master/allocator.proto to its own directory and package

2016-06-22 Thread Zhitao Li (JIRA)

[ 
https://issues.apache.org/jira/browse/MESOS-5642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15344924#comment-15344924
 ] 

Zhitao Li commented on MESOS-5642:
--

(Moving conversation from patch to here).

Based on conversations in r/48092, we also want to move non-versioned 
allocator.proto into its own directory. I tried to started a separate patch for 
it, but got stuck on how to handle the `mesos::master::allocator::Allocator` 
interface class in `include/mesos/master/allocator.hpp`. Ideally, I want to 
keep it in the new allocator directory too, but that would affect quite some 
places, and my most worry is that custom allocator module compilation would be 
broken because the base class is moved away.

I wonder whether a typedef alias is sufficient to maintain compile 
compatibility and give module maintainer some time to update. 

[~vinodkone], [~haosd...@gmail.com] and [~anandmazumdar], any thought on this?

> Move include/mesos/v1/master/allocator.proto to its own directory and package
> -
>
> Key: MESOS-5642
> URL: https://issues.apache.org/jira/browse/MESOS-5642
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API
>Reporter: Zhitao Li
>Assignee: Zhitao Li
> Fix For: 1.0.0
>
>
> Right now, all protobuf used in `include/mesos/v1` is in their own directory 
> and package except for allocator.
> We should do the same for it for both consistency, as well as protobuf 
> compiler friendliness (e.g. golang compiler doesn't work well when two .proto 
> files generates messages into same package).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MESOS-5642) Move include/mesos/v1/master/allocator.proto to its own directory and package

2016-06-18 Thread Zhitao Li (JIRA)

[ 
https://issues.apache.org/jira/browse/MESOS-5642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15337609#comment-15337609
 ] 

Zhitao Li commented on MESOS-5642:
--

[~vinodkone], given this changes output package of struct and could be 
considered as "backward incompatible", I think we should include in 1.0.0.

Can you take a look at the fix at https://reviews.apache.org/r/48902/? Thanks.

> Move include/mesos/v1/master/allocator.proto to its own directory and package
> -
>
> Key: MESOS-5642
> URL: https://issues.apache.org/jira/browse/MESOS-5642
> Project: Mesos
>  Issue Type: Bug
>  Components: HTTP API
>Reporter: Zhitao Li
>Assignee: Zhitao Li
> Fix For: 1.0.0
>
>
> Right now, all protobuf used in `include/mesos/v1` is in their own directory 
> and package except for allocator.
> We should do the same for it for both consistency, as well as protobuf 
> compiler friendliness (e.g. golang compiler doesn't work well when two .proto 
> files generates messages into same package).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)