Re: [VOTE] Release Apache Mesos 0.23.0 (rc4)

[Marco Massenzio]

+1

Run all tests on Ubuntu 14.04 (physical box, not a VM).
All tests pass (as regular user).

`sudo make distcheck` still fails with the following errors; I am assuming
these are "known issues" and not deemed to be blockers?

[  FAILED  ] 9 tests, listed below:
[  FAILED  ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
[  FAILED  ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
[  FAILED  ]
MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PerfRollForward
[  FAILED  ] CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
[  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
[  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
[  FAILED  ] NsTest.ROOT_setns
[  FAILED  ] PerfTest.ROOT_Events
[  FAILED  ] PerfTest.ROOT_SamplePid

I tried to check out 0.22.1 and run the same tests, but it has several
failures and it complains about already existing cgroups hierarchies; so
I'm assuming the earlier test run left the system in an unclean state.


*Marco Massenzio*
*Distributed Systems Engineer*

On Tue, Jul 21, 2015 at 3:12 PM, Adam Bordelon  wrote:

> +1 (binding) to Mesos 0.23.0-rc4 as 0.23.0
> As I mentioned before, for rc3, basic integration tests passed for Mesos 0
> .23.0 on CoreOS with DCOS GUI/CLI, Marathon, Chronos, Spark, HDFS,
> Cassandra, and Kafka.
>
> We have been tracking the Ubuntu `sudo make check` failures in
> https://issues.apache.org/jira/browse/MESOS-3079 and related CentOS ROOT_
> test failures in https://issues.apache.org/jira/browse/MESOS-3050 (some
> fixes already pulled into rc4).
> After pulling down the latest master, including a series of test code only
> fixes for MESOS-3079, `sudo make check` passed for me on Ubuntu 14.04,
> excluding only ROOT_DOCKER_Launch_Executor_Bridged (segfault tracked in
> MESOS-3123). There are at least two remaining test-only fixes tracked in
> MESOS-3079, but none of these are critical for Mesos 0.23.0, so I'm not
> inclined to call for a rc5. We can call out the ROOT_ test failures as a
> known issue with the release.
>
> Anybody else have any test results?
>
> Please vote,
> -Adam-
>
> On Fri, Jul 17, 2015 at 8:18 PM, Marco Massenzio 
> wrote:
>
>> I am almost sure (more like hoping) I'm missing something fundamental
>> here and/or there is some basic configuration missing on my box.
>> Running tests as root, causes a significant number of failures.
>>
>> Has anyone else *ever* run tests as root in the last few weeks?
>>
>> Here's the headline, the full log of the failed tests attached.
>>
>> $ lsb_release -a
>> LSB Version:
>>  
>> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
>> Distributor ID: Ubuntu
>> Description:*Ubuntu 14.04.2 LTS*
>> Release:14.04
>> Codename:   *trusty*
>>
>> $ sudo make -j12 V=0 check
>>
>> [==] 712 tests from 116 test cases ran. (318672 ms total)
>> [  PASSED  ] 676 tests.
>> [  FAILED  ] 36 tests, listed below:
>> [  FAILED  ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
>> [  FAILED  ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
>> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
>> [  FAILED  ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
>> mesos::internal::slave::MesosContainerizer
>> [  FAILED  ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where
>> TypeParam = mesos::internal::slave::MesosContainerizer
>> [  FAILED  ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
>> mesos::internal::slave::MesosContainerizer
>> [  FAILED  ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where
>> TypeParam = mesos::internal::slave::MesosContainerizer
>> [  FAILED  ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where
>> TypeParam = mesos::internal::slave::MesosContainerizer
>> [  FAILED  ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where
>> T

Re: Prepping for next release

[Adam Bordelon]

Thanks, Vinod.

I've got a handful of JIRAs I'd really like to see land in 0.24.0.
https://issues.apache.org/jira/browse/MESOS-2559 Do not use
RunTaskMessage.framework_id.
https://issues.apache.org/jira/browse/MESOS-2600 Add /reserve and
/unreserve endpoints on the master for dynamic reservation
https://issues.apache.org/jira/browse/MESOS-2998 Disable Persistent
Volumes, Dynamic Reservations via master flags
https://issues.apache.org/jira/browse/MESOS-3050 Failing ROOT_ tests in
0.23.0-rc3 on CentOS 7.1
https://issues.apache.org/jira/browse/MESOS-3079 `sudo make distcheck`
fails on Ubuntu 14.04 (and possibly other OSes too)

I understand your desire to untarget the majority of the tickets, since
it's a time-based release, but we might want to keep some of these targeted
so we can track the priority issues. When the actual rc1 cut date
approaches, it's pretty easy to aggressively push things out of the release
that haven't made it. Let me know what you think.

Cheers,
-A-


On Tue, Jul 21, 2015 at 11:02 AM, Vinod Kone  wrote:

> Hi folks,
>
> I will be the release manager for the upcoming release (ETA early August).
>
> To prep for the release (and make my life easy) I'm planning to remove the
> target versions for all *unresolved* tickets that have a target version
> 0.24.0.
>
> I would like folks to explicitly set the target version to 0.24.0* for
> tickets they want to absolutely land in the next release (keeping in mind
> the time frame). If you are unsure, please reach out to me or reply to this
> thread.
>
> The main blocking feature for this release is going to the new HTTP API.
>
> Thanks,
> Vinod
>
> P.S. If things go according to plan we might make this 1.0 release!
>

Re: building mesos.jar gives many errors at javadoc

[Adam Bordelon]

>From your pastebin, it looks like maven ran out of memory, either while
compiling or while generating javadoc.
After you give mvn more memory, it tries to javadoc the class files instead
of just java files. Weird. Do you have abnormal mvn/java settings? Let's
file a JIRA.
I'm glad you found a hacky workaround to get you moving. You can also try
`configure --disable-java` if you don't need to build the java language
bindings.

On Tue, Jul 21, 2015 at 7:35 AM, Hans van den Bogert 
wrote:

> Hi,
>
> When compiling mesos under centos 6.5, I get numerous errors at some
> point, which if I understand correctly, is at creating the mesos.jar, at
> the javadoc phase:
>
> I get the following:
> http://pastebin.com/TNRERS4p
>
> When I give mvn more JVM memory, actual errors appear (these are just two,
> of the __many__  instances that appear):
> [ERROR]
> /var/scratch/vdbogert/src/mesos-reproduce-error/build/src/java/target/classes/org/apache/mesos/Protos$DiscoveryInfo$Builder.class:149:
> error: unmappable character for encoding UTF-8
> [ERROR] 
> T*:*@~@"***k+lm*+*7*+aW*Y@TTR7*W**~*8*Y@7*bn>**do*O(**fY**g*hi**(#A#*pA#*qA9*+,r
> A.*+sA#*pA#*qA9*+,r A#*qA #*A #*tA!.*+sA#*pA#9*+,r
> A$#*qA%#*A%#*tA$#*pA%#*uA #*uA'9*+,r A(#*qA)#*q+.8*+ /123|6{}~@,6c,e6
>  .6n.o6   v   " & w60
> [ERROR] ^
> [ERROR]
> /var/scratch/vdbogert/src/mesos-reproduce-error/build/src/java/target/classes/org/apache/mesos/Protos$DiscoveryInfo$Builder.class:149:
> error: unmappable character for encoding UTF-8
> [ERROR] 
> T*:*@~@"***k+lm*+*7*+aW*Y@TTR7*W**~*8*Y@7*bn>**do*O(**fY**g*hi**(#A#*pA#*qA9*+,r
> A.*+sA#*pA#*qA9*+,r A#*qA #*A #*tA!.*+sA#*pA#9*+,r
> A$#*qA%#*A%#*tA$#*pA%#*uA #*uA'9*+,r A(#*qA)#*q+.8*+ /123|6{}~@,6c,e6
>  .6n.o6   v   " & w60
> [ERROR] ^
> [ERROR]
> /var/scratch/vdbogert/src/mesos-reproduce-error/build/src/java/target/classes/org/apache/mesos/Protos$DiscoveryInfo$Builder.class:149:
> error: unmappable character for encoding UTF-8
>
> When I ‘cd’ to src/java and manually do:
> $ mvn -f mesos.pom package  -Dmaven.javadoc.skip=true
>
> The jar file is created and I can continue with a simple make from the
> root of the mesos build dir.
>
> Is this an error in my configuration?
>
> If more environment info is needed let me know.
>
> Hans

Re: [VOTE] Release Apache Mesos 0.23.0 (rc4)

[Adam Bordelon]

+1 (binding) to Mesos 0.23.0-rc4 as 0.23.0
As I mentioned before, for rc3, basic integration tests passed for Mesos 0
.23.0 on CoreOS with DCOS GUI/CLI, Marathon, Chronos, Spark, HDFS,
Cassandra, and Kafka.

We have been tracking the Ubuntu `sudo make check` failures in
https://issues.apache.org/jira/browse/MESOS-3079 and related CentOS ROOT_
test failures in https://issues.apache.org/jira/browse/MESOS-3050 (some
fixes already pulled into rc4).
After pulling down the latest master, including a series of test code only
fixes for MESOS-3079, `sudo make check` passed for me on Ubuntu 14.04,
excluding only ROOT_DOCKER_Launch_Executor_Bridged (segfault tracked in
MESOS-3123). There are at least two remaining test-only fixes tracked in
MESOS-3079, but none of these are critical for Mesos 0.23.0, so I'm not
inclined to call for a rc5. We can call out the ROOT_ test failures as a
known issue with the release.

Anybody else have any test results?

Please vote,
-Adam-

On Fri, Jul 17, 2015 at 8:18 PM, Marco Massenzio 
wrote:

> I am almost sure (more like hoping) I'm missing something fundamental here
> and/or there is some basic configuration missing on my box.
> Running tests as root, causes a significant number of failures.
>
> Has anyone else *ever* run tests as root in the last few weeks?
>
> Here's the headline, the full log of the failed tests attached.
>
> $ lsb_release -a
> LSB Version:
>  
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:*Ubuntu 14.04.2 LTS*
> Release:14.04
> Codename:   *trusty*
>
> $ sudo make -j12 V=0 check
>
> [==] 712 tests from 116 test cases ran. (318672 ms total)
> [  PASSED  ] 676 tests.
> [  FAILED  ] 36 tests, listed below:
> [  FAILED  ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
> [  FAILED  ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
> TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
> [  FAILED  ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where TypeParam
> = mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.CleanupExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.RemoveNonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.NonCheckpointingFramework, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.KillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.Reboot, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.GCExecutor, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.ShutdownSlave, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.ShutdownSlaveSIGUSR1, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.RegisterDisconnectedSlave, where
> TypeParam = mesos::internal::slave::MesosContainerizer
> [  FAILED  ] SlaveRecoveryTest/0.ReconcileKillTask, where TypeParam =
> mesos::internal::slave::MesosContainerizer
> [  FAILE

Re: Resource Estimator

[Jie Yu]

Tiago,

ResourceEstimator is used for oversubscription and is irrelevant (
https://github.com/apache/mesos/blob/master/docs/oversubscription.md)

The logic of estimating available resources on a slave is here:
https://github.com/apache/mesos/blob/master/src/slave/containerizer/containerizer.cpp#L61

- Jie

On Tue, Jul 21, 2015 at 1:37 PM, Tiago Alves  wrote:

> Hi,
>
> I would like to know how mesos estimates the available resources
> (CPU/RAM/DISK) of a slave, and how this resources are viewed by the master
> (zookeeper ?)
>
> I have looked in:
>
> https://github.com/apache/mesos/blob/master/src/slave/resource_estimator.cpp
>
> https://github.com/apache/mesos/blob/master/src/slave/resource_estimators/*.cpp
>
> Can someone give a overview or point the direction of how mesos measures
> the resources ?
>
> Thank you,
> Tiago Alves
>

Resource Estimator

[Tiago Alves]

Hi,

I would like to know how mesos estimates the available resources
(CPU/RAM/DISK) of a slave, and how this resources are viewed by the master
(zookeeper ?)

I have looked in:
https://github.com/apache/mesos/blob/master/src/slave/resource_estimator.cpp
https://github.com/apache/mesos/blob/master/src/slave/resource_estimators/*.cpp

Can someone give a overview or point the direction of how mesos measures
the resources ?

Thank you,
Tiago Alves

Re: Prepping for next release

[Vinod Kone]

So far, we have maintained compatibility with version N and N-1.

Regarding support, we typically support the latest release and the previous
release.

On Tue, Jul 21, 2015 at 12:52 PM, James Peach  wrote:

>
> > On Jul 21, 2015, at 11:46 AM, Vinod Kone  wrote:
> >
> > In one of the previous community syncs, we decided to try time based
> > releases (roughly a month apart) going forward since 1) we have enough
> > meaty stuff landing every month and 2) gives users a cadence of releases.
>
> How long previous versions are supported for? Is <
> https://cwiki.apache.org/confluence/display/MESOS/Mesos+Release+Planning>
> the best release cycle document?
>
> > While 0.23.0 vote is still in progress, the first RC was cut July 3rd, so
> > cutting an RC for 24.0 early august follows the cadence.
> >
> > Regarding stable even releases, I personally don't like that idea. I
> would
> > like every release to be stable and well tested. That is one of the
> reasons
> > we are giving a longer vote time for RCs.
> >
> > Thanks
> >
> > On Tue, Jul 21, 2015 at 11:24 AM, haosdent  wrote:
> >
> >> Or odd number version is no stable version while the even number
> version is
> >> a stable version, just like HBase.
> >>
> >> On Wed, Jul 22, 2015 at 2:22 AM, haosdent  wrote:
> >>
> >>> Is it too fast to release 0.24, because 0.23 is still rc3 now.
> >>>
> >>> On Wed, Jul 22, 2015 at 2:02 AM, Vinod Kone 
> wrote:
> >>>
>  Hi folks,
> 
>  I will be the release manager for the upcoming release (ETA early
> >> August).
> 
>  To prep for the release (and make my life easy) I'm planning to remove
> >> the
>  target versions for all *unresolved* tickets that have a target
> version
>  0.24.0.
> 
>  I would like folks to explicitly set the target version to 0.24.0* for
>  tickets they want to absolutely land in the next release (keeping in
> >> mind
>  the time frame). If you are unsure, please reach out to me or reply to
>  this
>  thread.
> 
>  The main blocking feature for this release is going to the new HTTP
> API.
> 
>  Thanks,
>  Vinod
> 
>  P.S. If things go according to plan we might make this 1.0 release!
> 
> >>>
> >>>
> >>>
> >>> --
> >>> Best Regards,
> >>> Haosdent Huang
> >>>
> >>
> >>
> >>
> >> --
> >> Best Regards,
> >> Haosdent Huang
> >>
>
>

Re: Prepping for next release

[James Peach]

> On Jul 21, 2015, at 11:46 AM, Vinod Kone  wrote:
> 
> In one of the previous community syncs, we decided to try time based
> releases (roughly a month apart) going forward since 1) we have enough
> meaty stuff landing every month and 2) gives users a cadence of releases.

How long previous versions are supported for? Is 
 the 
best release cycle document?

> While 0.23.0 vote is still in progress, the first RC was cut July 3rd, so
> cutting an RC for 24.0 early august follows the cadence.
> 
> Regarding stable even releases, I personally don't like that idea. I would
> like every release to be stable and well tested. That is one of the reasons
> we are giving a longer vote time for RCs.
> 
> Thanks
> 
> On Tue, Jul 21, 2015 at 11:24 AM, haosdent  wrote:
> 
>> Or odd number version is no stable version while the even number version is
>> a stable version, just like HBase.
>> 
>> On Wed, Jul 22, 2015 at 2:22 AM, haosdent  wrote:
>> 
>>> Is it too fast to release 0.24, because 0.23 is still rc3 now.
>>> 
>>> On Wed, Jul 22, 2015 at 2:02 AM, Vinod Kone  wrote:
>>> 
 Hi folks,
 
 I will be the release manager for the upcoming release (ETA early
>> August).
 
 To prep for the release (and make my life easy) I'm planning to remove
>> the
 target versions for all *unresolved* tickets that have a target version
 0.24.0.
 
 I would like folks to explicitly set the target version to 0.24.0* for
 tickets they want to absolutely land in the next release (keeping in
>> mind
 the time frame). If you are unsure, please reach out to me or reply to
 this
 thread.
 
 The main blocking feature for this release is going to the new HTTP API.
 
 Thanks,
 Vinod
 
 P.S. If things go according to plan we might make this 1.0 release!
 
>>> 
>>> 
>>> 
>>> --
>>> Best Regards,
>>> Haosdent Huang
>>> 
>> 
>> 
>> 
>> --
>> Best Regards,
>> Haosdent Huang
>> 

Re: Prepping for next release

[Vinod Kone]

In one of the previous community syncs, we decided to try time based
releases (roughly a month apart) going forward since 1) we have enough
meaty stuff landing every month and 2) gives users a cadence of releases.

While 0.23.0 vote is still in progress, the first RC was cut July 3rd, so
cutting an RC for 24.0 early august follows the cadence.

Regarding stable even releases, I personally don't like that idea. I would
like every release to be stable and well tested. That is one of the reasons
we are giving a longer vote time for RCs.

Thanks

On Tue, Jul 21, 2015 at 11:24 AM, haosdent  wrote:

> Or odd number version is no stable version while the even number version is
> a stable version, just like HBase.
>
> On Wed, Jul 22, 2015 at 2:22 AM, haosdent  wrote:
>
> > Is it too fast to release 0.24, because 0.23 is still rc3 now.
> >
> > On Wed, Jul 22, 2015 at 2:02 AM, Vinod Kone  wrote:
> >
> >> Hi folks,
> >>
> >> I will be the release manager for the upcoming release (ETA early
> August).
> >>
> >> To prep for the release (and make my life easy) I'm planning to remove
> the
> >> target versions for all *unresolved* tickets that have a target version
> >> 0.24.0.
> >>
> >> I would like folks to explicitly set the target version to 0.24.0* for
> >> tickets they want to absolutely land in the next release (keeping in
> mind
> >> the time frame). If you are unsure, please reach out to me or reply to
> >> this
> >> thread.
> >>
> >> The main blocking feature for this release is going to the new HTTP API.
> >>
> >> Thanks,
> >> Vinod
> >>
> >> P.S. If things go according to plan we might make this 1.0 release!
> >>
> >
> >
> >
> > --
> > Best Regards,
> > Haosdent Huang
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Prepping for next release

[haosdent]

Or odd number version is no stable version while the even number version is
a stable version, just like HBase.

On Wed, Jul 22, 2015 at 2:22 AM, haosdent  wrote:

> Is it too fast to release 0.24, because 0.23 is still rc3 now.
>
> On Wed, Jul 22, 2015 at 2:02 AM, Vinod Kone  wrote:
>
>> Hi folks,
>>
>> I will be the release manager for the upcoming release (ETA early August).
>>
>> To prep for the release (and make my life easy) I'm planning to remove the
>> target versions for all *unresolved* tickets that have a target version
>> 0.24.0.
>>
>> I would like folks to explicitly set the target version to 0.24.0* for
>> tickets they want to absolutely land in the next release (keeping in mind
>> the time frame). If you are unsure, please reach out to me or reply to
>> this
>> thread.
>>
>> The main blocking feature for this release is going to the new HTTP API.
>>
>> Thanks,
>> Vinod
>>
>> P.S. If things go according to plan we might make this 1.0 release!
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>



-- 
Best Regards,
Haosdent Huang

Re: Prepping for next release

[haosdent]

Is it too fast to release 0.24, because 0.23 is still rc3 now.

On Wed, Jul 22, 2015 at 2:02 AM, Vinod Kone  wrote:

> Hi folks,
>
> I will be the release manager for the upcoming release (ETA early August).
>
> To prep for the release (and make my life easy) I'm planning to remove the
> target versions for all *unresolved* tickets that have a target version
> 0.24.0.
>
> I would like folks to explicitly set the target version to 0.24.0* for
> tickets they want to absolutely land in the next release (keeping in mind
> the time frame). If you are unsure, please reach out to me or reply to this
> thread.
>
> The main blocking feature for this release is going to the new HTTP API.
>
> Thanks,
> Vinod
>
> P.S. If things go according to plan we might make this 1.0 release!
>



-- 
Best Regards,
Haosdent Huang

Prepping for next release

[Vinod Kone]

Hi folks,

I will be the release manager for the upcoming release (ETA early August).

To prep for the release (and make my life easy) I'm planning to remove the
target versions for all *unresolved* tickets that have a target version
0.24.0.

I would like folks to explicitly set the target version to 0.24.0* for
tickets they want to absolutely land in the next release (keeping in mind
the time frame). If you are unsure, please reach out to me or reply to this
thread.

The main blocking feature for this release is going to the new HTTP API.

Thanks,
Vinod

P.S. If things go according to plan we might make this 1.0 release!

building mesos.jar gives many errors at javadoc

[Hans van den Bogert]

Hi, 

When compiling mesos under centos 6.5, I get numerous errors at some point, 
which if I understand correctly, is at creating the mesos.jar, at the javadoc 
phase:

I get the following:
http://pastebin.com/TNRERS4p

When I give mvn more JVM memory, actual errors appear (these are just two, of 
the __many__  instances that appear):
[ERROR] 
/var/scratch/vdbogert/src/mesos-reproduce-error/build/src/java/target/classes/org/apache/mesos/Protos$DiscoveryInfo$Builder.class:149:
 error: unmappable character for encoding UTF-8
[ERROR] 
T*:*@~@"***k+lm*+*7*+aW*Y@TTR7*W**~*8*Y@7*bn>**do*O(**fY**g*hi**(#A#*pA#*qA9*+,r
 A.*+sA#*pA#*qA9*+,r A#*qA #*A #*tA!.*+sA#*pA#9*+,r A$#*qA%#*A%#*tA$#*pA%#*uA 
#*uA'9*+,r A(#*qA)#*q+.8*+ /123|6{}~@,6c,e6   .6n.o6   v   "
 & w60
[ERROR] ^
[ERROR] 
/var/scratch/vdbogert/src/mesos-reproduce-error/build/src/java/target/classes/org/apache/mesos/Protos$DiscoveryInfo$Builder.class:149:
 error: unmappable character for encoding UTF-8
[ERROR] 
T*:*@~@"***k+lm*+*7*+aW*Y@TTR7*W**~*8*Y@7*bn>**do*O(**fY**g*hi**(#A#*pA#*qA9*+,r
 A.*+sA#*pA#*qA9*+,r A#*qA #*A #*tA!.*+sA#*pA#9*+,r A$#*qA%#*A%#*tA$#*pA%#*uA 
#*uA'9*+,r A(#*qA)#*q+.8*+ /123|6{}~@,6c,e6   .6n.o6   v   "
 & w60
[ERROR] ^
[ERROR] 
/var/scratch/vdbogert/src/mesos-reproduce-error/build/src/java/target/classes/org/apache/mesos/Protos$DiscoveryInfo$Builder.class:149:
 error: unmappable character for encoding UTF-8

When I ‘cd’ to src/java and manually do:
$ mvn -f mesos.pom package  -Dmaven.javadoc.skip=true

The jar file is created and I can continue with a simple make from the root of 
the mesos build dir.

Is this an error in my configuration?

If more environment info is needed let me know.

Hans