[jira] [Comment Edited] (MESOS-10129) Build fails on Maven javadoc generation when using JDK11
[
https://issues.apache.org/jira/browse/MESOS-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17369026#comment-17369026
]
Saad Ur Rahman edited comment on MESOS-10129 at 6/24/21, 6:46 PM:
--
I am on it. I just ran a clean build of Mesos from the updated _upstream:main_
without issues.
*OS:* Ubuntu 21.04
*Javac:* openjdk-11-jdk-headless:amd64:
/usr/lib/jvm/java-11-openjdk-amd64/bin/javac
*Java:* openjdk-11-jre-headless:amd64:
/usr/lib/jvm/java-11-openjdk-amd64/bin/java
Sorry, I am still a bit of a newbie with Mesos, is there a specific build
command I should run to try and replicate this? It might be a Debian-specific
issue.
was (Author: surahman):
I am on it.
> Build fails on Maven javadoc generation when using JDK11
>
>
> Key: MESOS-10129
> URL: https://issues.apache.org/jira/browse/MESOS-10129
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: master, 1.10.0
> Environment: Debian 10 Buster (2020-04-29) with OpenJdk 11.0.7
> (2020-04-14)
>Reporter: Carlos Saltos
>Priority: Major
> Labels: Java11, beginner, build, java11, jdk11
> Attachments: mesos.10.0.maven.javadoc.fix.patch
>
>
> h3. CURRENT BEHAVIOR:
> When using Java 11 (or newer versions) the Javadoc generation step fails with
> the error:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar
> (build-and-attach-javadocs) on project mesos: MavenReportException: Error
> while creating archive:}}
> {{[ERROR] Exit code: 1 - javadoc: error - The code being documented uses
> modules but the packages defined in
> http://download.oracle.com/javase/6/docs/api/ are in the unnamed module.}}
> {{[ERROR]}}
> {{[ERROR] Command line was: /usr/lib/jvm/java-11-openjdk-amd64/bin/javadoc
> @options}}
> {{[ERROR]}}
> {{[ERROR] Refer to the generated Javadoc files in
> '/home/admin/mesos-deb-packaging/mesos-repo/build/src/java/target/apidocs'
> dir.}}
> {{[ERROR] -> [Help 1]}}
> {{[ERROR]}}
> {{[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.}}
> {{[ERROR] Re-run Maven using the -X switch to enable full debug logging.}}
> {{[ERROR]}}
> {{[ERROR] For more information about the errors and possible solutions,
> please read the following articles:}}
> {{[ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException}}
> {{make[1]: *** [Makefile:17533: java/target/mesos-1.11.0.jar] Error 1}}
> {{make[1]: Leaving directory
> '/home/admin/mesos-deb-packaging/mesos-repo/build/src'}}
> {{make: *** [Makefile:785: all-recursive] Error 1}}
> *NOTE:* The error is at the Maven javadoc plugin call when it tries to
> include references to the non-existant old Java 6 documentation.
> h3. POSSIBLE SOLUTION:
> Just remove the old reference with adding
> false to the javadoc maven plugin
> configuration section
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MESOS-10129) Build fails on Maven javadoc generation when using JDK11
[
https://issues.apache.org/jira/browse/MESOS-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17369026#comment-17369026
]
Saad Ur Rahman commented on MESOS-10129:
I am on it.
> Build fails on Maven javadoc generation when using JDK11
>
>
> Key: MESOS-10129
> URL: https://issues.apache.org/jira/browse/MESOS-10129
> Project: Mesos
> Issue Type: Bug
> Components: build
>Affects Versions: master, 1.10.0
> Environment: Debian 10 Buster (2020-04-29) with OpenJdk 11.0.7
> (2020-04-14)
>Reporter: Carlos Saltos
>Priority: Major
> Labels: Java11, beginner, build, java11, jdk11
> Attachments: mesos.10.0.maven.javadoc.fix.patch
>
>
> h3. CURRENT BEHAVIOR:
> When using Java 11 (or newer versions) the Javadoc generation step fails with
> the error:
> {{[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:jar
> (build-and-attach-javadocs) on project mesos: MavenReportException: Error
> while creating archive:}}
> {{[ERROR] Exit code: 1 - javadoc: error - The code being documented uses
> modules but the packages defined in
> http://download.oracle.com/javase/6/docs/api/ are in the unnamed module.}}
> {{[ERROR]}}
> {{[ERROR] Command line was: /usr/lib/jvm/java-11-openjdk-amd64/bin/javadoc
> @options}}
> {{[ERROR]}}
> {{[ERROR] Refer to the generated Javadoc files in
> '/home/admin/mesos-deb-packaging/mesos-repo/build/src/java/target/apidocs'
> dir.}}
> {{[ERROR] -> [Help 1]}}
> {{[ERROR]}}
> {{[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.}}
> {{[ERROR] Re-run Maven using the -X switch to enable full debug logging.}}
> {{[ERROR]}}
> {{[ERROR] For more information about the errors and possible solutions,
> please read the following articles:}}
> {{[ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException}}
> {{make[1]: *** [Makefile:17533: java/target/mesos-1.11.0.jar] Error 1}}
> {{make[1]: Leaving directory
> '/home/admin/mesos-deb-packaging/mesos-repo/build/src'}}
> {{make: *** [Makefile:785: all-recursive] Error 1}}
> *NOTE:* The error is at the Maven javadoc plugin call when it tries to
> include references to the non-existant old Java 6 documentation.
> h3. POSSIBLE SOLUTION:
> Just remove the old reference with adding
> false to the javadoc maven plugin
> configuration section
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17368412#comment-17368412
]
Saad Ur Rahman commented on MESOS-10224:
[~cf.natali], thank you. I have created a PR:
[https://github.com/apache/mesos/pull/394]
> [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
> -
>
> Key: MESOS-10224
> URL: https://issues.apache.org/jira/browse/MESOS-10224
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.11.0
>Reporter: Saad Ur Rahman
>Priority: Major
> Attachments: ld.so.cache
>
>
> *OS:* Ubuntu 21.04
> *Command:*
> {code:java}
> make -j 6 V=0 check{code}
> Fails during the build and test suite run on two different machines with the
> same OS.
> {code:java}
> 3: [ OK ] CSIVersion/StorageLocalResourceProviderTest.Update/v0 (479 ms)
> 3: [--] 14 tests from CSIVersion/StorageLocalResourceProviderTest
> (27011 ms total)
> 3:
> 3: [--] Global test environment tear-down
> 3: [==] 575 tests from 178 test cases ran. (202572 ms total)
> 3: [ PASSED ] 573 tests.
> 3: [ FAILED ] 2 tests, listed below:
> 3: [ FAILED ] LdcacheTest.Parse
> 3: [ FAILED ]
> CSIVersion/StorageLocalResourceProviderTest.OperationUpdate/v0, where
> GetParam() = "v0"
> 3:
> 3: 2 FAILED TESTS
> 3: YOU HAVE 34 DISABLED TESTS
> 3:
> 3:
> 3:
> 3: [FAIL]: 4 shard(s) have failed tests
> 3/3 Test #3: MesosTests ...***Failed 1173.43 sec
> {code}
> Are there any pre-requisites required to get the build/tests to pass? I am
> trying to get all the tests to pass to make sure my build environment is
> setup correctly for development.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367775#comment-17367775
]
Saad Ur Rahman edited comment on MESOS-10224 at 6/23/21, 4:51 PM:
--
[~cf.natali], I am finally getting around to patching the issue here.
My understanding of the routine is that it parses the linker library to
generate a vector of library names and paths. It does this by casting memory
blocks into structs to give them parsable structure.
The failing conditional on line _#227_ is because of the droppings Ubuntu
leaves at the end of the file. The data pointer should point to the end of the
file to indicate complete parsing. The following conditional on line _#235_
ensures NUL termination.
The solutions I can think of are to adjust for the end of data specifically for
Ubuntu (if we can) by setting:
{code:java}
data = buffer->size();
{code}
Or we can do this if the data pointer is not at the end:
{code:java}
if ((size_t)(data - buffer->data()) < buffer->size())
{code}
Another thing we can is let it slide if the data pointer is less than or equal
to the buffer size on line _#227_:
{code:java}
if ((size_t)(data - buffer->data()) > buffer->size()) {
return Error("Invalid format");
}
{code}
What are your thoughts? All of the above are quick adjustments but they weaken
the original checks.
was (Author: surahman):
[~cf.natali], I am finally getting around to patching the issue here.
My understanding of the routine is that it parses the linker library to
generate a vector of library names and paths. It does this by casting memory
blocks into structs to give them parsable structure.
The failing conditional on line _#227_ is because of the droppings Ubuntu
leaves at the end of the file. The data pointer should point to the end of the
file to indicate complete parsing. The following conditional on line _#235_
ensures NUL termination.
The solutions I can think of are to adjust for the end of data specifically for
Ubuntu (if we can) by setting:
{code:java}
data = buffer->size();
{code}
Or we can do this if the data pointer is not at the end:
{code:java}
if ((size_t)(data - buffer->data()) < buffer->size())
{code}
Another thing we can is let it slide if the data pointer is strictly less than
the buffer size on line _#227_:
{code:java}
if ((size_t)(data - buffer->data()) > buffer->size()) {
return Error("Invalid format");
}
{code}
What are your thoughts? All of the above are quick adjustments.
> [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
> -
>
> Key: MESOS-10224
> URL: https://issues.apache.org/jira/browse/MESOS-10224
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.11.0
>Reporter: Saad Ur Rahman
>Priority: Major
> Attachments: ld.so.cache
>
>
> *OS:* Ubuntu 21.04
> *Command:*
> {code:java}
> make -j 6 V=0 check{code}
> Fails during the build and test suite run on two different machines with the
> same OS.
> {code:java}
> 3: [ OK ] CSIVersion/StorageLocalResourceProviderTest.Update/v0 (479 ms)
> 3: [--] 14 tests from CSIVersion/StorageLocalResourceProviderTest
> (27011 ms total)
> 3:
> 3: [--] Global test environment tear-down
> 3: [==] 575 tests from 178 test cases ran. (202572 ms total)
> 3: [ PASSED ] 573 tests.
> 3: [ FAILED ] 2 tests, listed below:
> 3: [ FAILED ] LdcacheTest.Parse
> 3: [ FAILED ]
> CSIVersion/StorageLocalResourceProviderTest.OperationUpdate/v0, where
> GetParam() = "v0"
> 3:
> 3: 2 FAILED TESTS
> 3: YOU HAVE 34 DISABLED TESTS
> 3:
> 3:
> 3:
> 3: [FAIL]: 4 shard(s) have failed tests
> 3/3 Test #3: MesosTests ...***Failed 1173.43 sec
> {code}
> Are there any pre-requisites required to get the build/tests to pass? I am
> trying to get all the tests to pass to make sure my build environment is
> setup correctly for development.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367775#comment-17367775
]
Saad Ur Rahman commented on MESOS-10224:
[~cf.natali], I am finally getting around to patching the issue here.
My understanding of the routine is that it parses the linker library to
generate a vector of library names and paths. It does this by casting memory
blocks into structs to give them parsable structure.
The failing conditional on line _#227_ is because of the droppings Ubuntu
leaves at the end of the file. The data pointer should point to the end of the
file to indicate complete parsing. The following conditional on line _#235_
ensures NUL termination.
The solutions I can think of are to adjust for the end of data specifically for
Ubuntu (if we can) by setting:
{code:java}
data = buffer->size();
{code}
Or we can do this if the data pointer is not at the end:
{code:java}
if ((size_t)(data - buffer->data()) < buffer->size())
{code}
Another thing we can is let it slide if the data pointer is strictly less than
the buffer size on line _#227_:
{code:java}
if ((size_t)(data - buffer->data()) > buffer->size()) {
return Error("Invalid format");
}
{code}
What are your thoughts? All of the above are quick adjustments.
> [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
> -
>
> Key: MESOS-10224
> URL: https://issues.apache.org/jira/browse/MESOS-10224
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.11.0
>Reporter: Saad Ur Rahman
>Priority: Major
> Attachments: ld.so.cache
>
>
> *OS:* Ubuntu 21.04
> *Command:*
> {code:java}
> make -j 6 V=0 check{code}
> Fails during the build and test suite run on two different machines with the
> same OS.
> {code:java}
> 3: [ OK ] CSIVersion/StorageLocalResourceProviderTest.Update/v0 (479 ms)
> 3: [--] 14 tests from CSIVersion/StorageLocalResourceProviderTest
> (27011 ms total)
> 3:
> 3: [--] Global test environment tear-down
> 3: [==] 575 tests from 178 test cases ran. (202572 ms total)
> 3: [ PASSED ] 573 tests.
> 3: [ FAILED ] 2 tests, listed below:
> 3: [ FAILED ] LdcacheTest.Parse
> 3: [ FAILED ]
> CSIVersion/StorageLocalResourceProviderTest.OperationUpdate/v0, where
> GetParam() = "v0"
> 3:
> 3: 2 FAILED TESTS
> 3: YOU HAVE 34 DISABLED TESTS
> 3:
> 3:
> 3:
> 3: [FAIL]: 4 shard(s) have failed tests
> 3/3 Test #3: MesosTests ...***Failed 1173.43 sec
> {code}
> Are there any pre-requisites required to get the build/tests to pass? I am
> trying to get all the tests to pass to make sure my build environment is
> setup correctly for development.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367609#comment-17367609
]
Saad Ur Rahman commented on MESOS-10224:
[~cf.natali] thank you! I will get the PR in today. This will give me the
opportunity to get hands-on with the workflow on Apache projects :)
> [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
> -
>
> Key: MESOS-10224
> URL: https://issues.apache.org/jira/browse/MESOS-10224
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.11.0
>Reporter: Saad Ur Rahman
>Priority: Major
> Attachments: ld.so.cache
>
>
> *OS:* Ubuntu 21.04
> *Command:*
> {code:java}
> make -j 6 V=0 check{code}
> Fails during the build and test suite run on two different machines with the
> same OS.
> {code:java}
> 3: [ OK ] CSIVersion/StorageLocalResourceProviderTest.Update/v0 (479 ms)
> 3: [--] 14 tests from CSIVersion/StorageLocalResourceProviderTest
> (27011 ms total)
> 3:
> 3: [--] Global test environment tear-down
> 3: [==] 575 tests from 178 test cases ran. (202572 ms total)
> 3: [ PASSED ] 573 tests.
> 3: [ FAILED ] 2 tests, listed below:
> 3: [ FAILED ] LdcacheTest.Parse
> 3: [ FAILED ]
> CSIVersion/StorageLocalResourceProviderTest.OperationUpdate/v0, where
> GetParam() = "v0"
> 3:
> 3: 2 FAILED TESTS
> 3: YOU HAVE 34 DISABLED TESTS
> 3:
> 3:
> 3:
> 3: [FAIL]: 4 shard(s) have failed tests
> 3/3 Test #3: MesosTests ...***Failed 1173.43 sec
> {code}
> Are there any pre-requisites required to get the build/tests to pass? I am
> trying to get all the tests to pass to make sure my build environment is
> setup correctly for development.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367576#comment-17367576
]
Saad Ur Rahman commented on MESOS-10224:
[~cf.natali] thanks! I will follow along with on this one. I am not 100%
comfortable making the changes to get this to pass because I do not want to
break things for other configurations.
> [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
> -
>
> Key: MESOS-10224
> URL: https://issues.apache.org/jira/browse/MESOS-10224
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.11.0
>Reporter: Saad Ur Rahman
>Priority: Major
> Attachments: ld.so.cache
>
>
> *OS:* Ubuntu 21.04
> *Command:*
> {code:java}
> make -j 6 V=0 check{code}
> Fails during the build and test suite run on two different machines with the
> same OS.
> {code:java}
> 3: [ OK ] CSIVersion/StorageLocalResourceProviderTest.Update/v0 (479 ms)
> 3: [--] 14 tests from CSIVersion/StorageLocalResourceProviderTest
> (27011 ms total)
> 3:
> 3: [--] Global test environment tear-down
> 3: [==] 575 tests from 178 test cases ran. (202572 ms total)
> 3: [ PASSED ] 573 tests.
> 3: [ FAILED ] 2 tests, listed below:
> 3: [ FAILED ] LdcacheTest.Parse
> 3: [ FAILED ]
> CSIVersion/StorageLocalResourceProviderTest.OperationUpdate/v0, where
> GetParam() = "v0"
> 3:
> 3: 2 FAILED TESTS
> 3: YOU HAVE 34 DISABLED TESTS
> 3:
> 3:
> 3:
> 3: [FAIL]: 4 shard(s) have failed tests
> 3/3 Test #3: MesosTests ...***Failed 1173.43 sec
> {code}
> Are there any pre-requisites required to get the build/tests to pass? I am
> trying to get all the tests to pass to make sure my build environment is
> setup correctly for development.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367567#comment-17367567
]
Saad Ur Rahman edited comment on MESOS-10224 at 6/22/21, 6:07 PM:
--
[~qianzhang] thanks for getting back to me. My upstream is up to date and I am
building on the main branch - still no joy. I ran a clean git clone, build, and
then test with the same error. I am attaching my [^ld.so.cache] for inspection,
if it helps.
was (Author: surahman):
[~qianzhang] thanks for getting back to me. My upstream is up to date and I am
building on the main branch - still no joy. I ran a clean git clone, build, and
then test with the same error. I am attaching my [^ld.so.cache] for inspection,
if it helps.
> [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
> -
>
> Key: MESOS-10224
> URL: https://issues.apache.org/jira/browse/MESOS-10224
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.11.0
>Reporter: Saad Ur Rahman
>Priority: Major
> Attachments: ld.so.cache
>
>
> *OS:* Ubuntu 21.04
> *Command:*
> {code:java}
> make -j 6 V=0 check{code}
> Fails during the build and test suite run on two different machines with the
> same OS.
> {code:java}
> 3: [ OK ] CSIVersion/StorageLocalResourceProviderTest.Update/v0 (479 ms)
> 3: [--] 14 tests from CSIVersion/StorageLocalResourceProviderTest
> (27011 ms total)
> 3:
> 3: [--] Global test environment tear-down
> 3: [==] 575 tests from 178 test cases ran. (202572 ms total)
> 3: [ PASSED ] 573 tests.
> 3: [ FAILED ] 2 tests, listed below:
> 3: [ FAILED ] LdcacheTest.Parse
> 3: [ FAILED ]
> CSIVersion/StorageLocalResourceProviderTest.OperationUpdate/v0, where
> GetParam() = "v0"
> 3:
> 3: 2 FAILED TESTS
> 3: YOU HAVE 34 DISABLED TESTS
> 3:
> 3:
> 3:
> 3: [FAIL]: 4 shard(s) have failed tests
> 3/3 Test #3: MesosTests ...***Failed 1173.43 sec
> {code}
> Are there any pre-requisites required to get the build/tests to pass? I am
> trying to get all the tests to pass to make sure my build environment is
> setup correctly for development.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367567#comment-17367567
]
Saad Ur Rahman commented on MESOS-10224:
[~qianzhang] thanks for getting back to me. My upstream is up to date and I am
building on the main branch - still no joy. I ran a clean git clone, build, and
then test with the same error. I am attaching my [^ld.so.cache] for inspection,
if it helps.
> [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
> -
>
> Key: MESOS-10224
> URL: https://issues.apache.org/jira/browse/MESOS-10224
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.11.0
>Reporter: Saad Ur Rahman
>Priority: Major
> Attachments: ld.so.cache
>
>
> *OS:* Ubuntu 21.04
> *Command:*
> {code:java}
> make -j 6 V=0 check{code}
> Fails during the build and test suite run on two different machines with the
> same OS.
> {code:java}
> 3: [ OK ] CSIVersion/StorageLocalResourceProviderTest.Update/v0 (479 ms)
> 3: [--] 14 tests from CSIVersion/StorageLocalResourceProviderTest
> (27011 ms total)
> 3:
> 3: [--] Global test environment tear-down
> 3: [==] 575 tests from 178 test cases ran. (202572 ms total)
> 3: [ PASSED ] 573 tests.
> 3: [ FAILED ] 2 tests, listed below:
> 3: [ FAILED ] LdcacheTest.Parse
> 3: [ FAILED ]
> CSIVersion/StorageLocalResourceProviderTest.OperationUpdate/v0, where
> GetParam() = "v0"
> 3:
> 3: 2 FAILED TESTS
> 3: YOU HAVE 34 DISABLED TESTS
> 3:
> 3:
> 3:
> 3: [FAIL]: 4 shard(s) have failed tests
> 3/3 Test #3: MesosTests ...***Failed 1173.43 sec
> {code}
> Are there any pre-requisites required to get the build/tests to pass? I am
> trying to get all the tests to pass to make sure my build environment is
> setup correctly for development.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366900#comment-17366900
]
Saad Ur Rahman edited comment on MESOS-10224 at 6/22/21, 12:16 AM:
---
Hi [~qianzhang], thanks for checking on this:
{code:java}
-
We cannot run any aufs tests because:
aufs is not supported on your systems
-
-
We cannot run any cgroups tests that require mounting
hierarchies because you have the following hierarchies mounted:
/sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu,cpuacct, /sys/fs/cgroup/cpuset,
/sys/fs/cgroup/devices, /sys/fs/cgroup/freezer, /sys/fs/cgroup/hugetlb,
/sys/fs/cgroup/memory, /sys/fs/cgroup/net_cls,net_prio,
/sys/fs/cgroup/perf_event, /sys/fs/cgroup/pids, /sys/fs/cgroup/rdma,
/sys/fs/cgroup/systemd
We'll disable the CgroupsNoHierarchyTest test fixture for now.
-
-
We cannot run any Docker tests because:
Failed to get docker version: Failed to execute 'docker -H
unix:///var/run/docker.sock --version': exited with status 127
-
PING google.com (172.217.165.14) 56(84) bytes of data.
64 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=1 ttl=115
time=5.62 ms--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.617/5.617/5.617/0.000 ms
# Warning: iptables-legacy tables present, use iptables-legacy to see them
-
We cannot run any overlayfs tests because:
overlayfs is not supported on your systems
-
E0621 19:40:00.390394 8397 perf.cpp:251] Failed to get perf version: Failed to
execute perf: exited with status 2
-
Could not find the 'perf' command or its version lower that 2.6.39 so tests
using it to sample the 'cpu-cycles' hardware event will not be run.
-
E0621 19:40:00.489571 8397 perf.cpp:251] Failed to get perf version: Failed to
execute perf: exited with status 2
-
require 'perf' version >= 2.6.39 so no 'perf' tests will be run
-
-
We can't run any VETH tests:
iproute2 version is not an integer
-
-
We cannot run any xfs tests because:
xfs is not supported on your systems
-
Note: Google Test filter =
LdcacheTest.Parse-DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthyTask:DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthStatusChange:DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthyTaskWithQuotedCommand:BENCHMARK_HierarchicalAllocations.MultiFrameworkAllocations:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerTaskExecutorDecorator:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerValidator:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerHook:HookTest.ROOT_DOCKER_VerifySlavePostFetchHook:Resources_Filter_BENCHMARK_Test.Filters:CommonSorterTest/0.BENCHMARK_FullSort:CommonSorterTest/0.BENCHMARK_HierarchyFullSort:CommonSorterTest/1.BENCHMARK_FullSort:CommonSorterTest/1.BENCHMARK_HierarchyFullSort:DockerContainerizerTest.ROOT_DOCKER_Launch_Executor:DockerContainerizerTest.DISABLED_ROOT_DOCKER_Launch_Executor_Bridged:DockerContainerizerTest.ROOT_DOCKER_Launch:DockerContainerizerTest.ROOT_DOCKER_MaxCompletionTime:DockerContainerizerTest.ROOT_DOCKER_Kill:DockerContainerizerTest.ROOT_DOCKER_TaskKillingCapability:DockerContainerizerTest.ROOT_DOCKER_Usage:DockerContainerizerTest.ROOT_DOCKER_Recover:DockerContainerizerTest.ROOT_DOCKER_KillOrphanContainers:DockerContainerizerTest.ROOT_DOCKER_SkipRecoverNonDocker:DockerContainerizerTest.ROOT_DOCKER_SkipRecoverMalformedUUID:DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_RecoverPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_RecoverOrphanedPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_Logs:DockerContainerizerTest.ROOT_DOCKER_Default_CMD:DockerContainerizerTest.ROOT_DOCKER_Default_CMD_Override:DockerContainerizerTest.ROOT_DOCKER_Default_CMD_Args:DockerContainerizerTest.ROOT_DOCKER_SlaveRecoveryTaskContainer:DockerContainerizerTest.DISABLED_ROOT_DOCKER_SlaveRecoveryExecutorContainer:DockerContainerizerT
[jira] [Comment Edited] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366900#comment-17366900
]
Saad Ur Rahman edited comment on MESOS-10224 at 6/22/21, 12:11 AM:
---
Hi [~qianzhang], thanks for checking on this:
{code:java}
-
We cannot run any aufs tests because:
aufs is not supported on your systems
-
-
We cannot run any cgroups tests that require mounting
hierarchies because you have the following hierarchies mounted:
/sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu,cpuacct, /sys/fs/cgroup/cpuset,
/sys/fs/cgroup/devices, /sys/fs/cgroup/freezer, /sys/fs/cgroup/hugetlb,
/sys/fs/cgroup/memory, /sys/fs/cgroup/net_cls,net_prio,
/sys/fs/cgroup/perf_event, /sys/fs/cgroup/pids, /sys/fs/cgroup/rdma,
/sys/fs/cgroup/systemd
We'll disable the CgroupsNoHierarchyTest test fixture for now.
-
-
We cannot run any Docker tests because:
Failed to get docker version: Failed to execute 'docker -H
unix:///var/run/docker.sock --version': exited with status 127
-
PING google.com (172.217.165.14) 56(84) bytes of data.
64 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=1 ttl=115
time=5.62 ms--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.617/5.617/5.617/0.000 ms
# Warning: iptables-legacy tables present, use iptables-legacy to see them
-
We cannot run any overlayfs tests because:
overlayfs is not supported on your systems
-
E0621 19:40:00.390394 8397 perf.cpp:251] Failed to get perf version: Failed to
execute perf: exited with status 2
-
Could not find the 'perf' command or its version lower that 2.6.39 so tests
using it to sample the 'cpu-cycles' hardware event will not be run.
-
E0621 19:40:00.489571 8397 perf.cpp:251] Failed to get perf version: Failed to
execute perf: exited with status 2
-
require 'perf' version >= 2.6.39 so no 'perf' tests will be run
-
-
We can't run any VETH tests:
iproute2 version is not an integer
-
-
We cannot run any xfs tests because:
xfs is not supported on your systems
-
Note: Google Test filter =
LdcacheTest.Parse-DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthyTask:DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthStatusChange:DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthyTaskWithQuotedCommand:BENCHMARK_HierarchicalAllocations.MultiFrameworkAllocations:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerTaskExecutorDecorator:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerValidator:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerHook:HookTest.ROOT_DOCKER_VerifySlavePostFetchHook:Resources_Filter_BENCHMARK_Test.Filters:CommonSorterTest/0.BENCHMARK_FullSort:CommonSorterTest/0.BENCHMARK_HierarchyFullSort:CommonSorterTest/1.BENCHMARK_FullSort:CommonSorterTest/1.BENCHMARK_HierarchyFullSort:DockerContainerizerTest.ROOT_DOCKER_Launch_Executor:DockerContainerizerTest.DISABLED_ROOT_DOCKER_Launch_Executor_Bridged:DockerContainerizerTest.ROOT_DOCKER_Launch:DockerContainerizerTest.ROOT_DOCKER_MaxCompletionTime:DockerContainerizerTest.ROOT_DOCKER_Kill:DockerContainerizerTest.ROOT_DOCKER_TaskKillingCapability:DockerContainerizerTest.ROOT_DOCKER_Usage:DockerContainerizerTest.ROOT_DOCKER_Recover:DockerContainerizerTest.ROOT_DOCKER_KillOrphanContainers:DockerContainerizerTest.ROOT_DOCKER_SkipRecoverNonDocker:DockerContainerizerTest.ROOT_DOCKER_SkipRecoverMalformedUUID:DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_RecoverPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_RecoverOrphanedPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_Logs:DockerContainerizerTest.ROOT_DOCKER_Default_CMD:DockerContainerizerTest.ROOT_DOCKER_Default_CMD_Override:DockerContainerizerTest.ROOT_DOCKER_Default_CMD_Args:DockerContainerizerTest.ROOT_DOCKER_SlaveRecoveryTaskContainer:DockerContainerizerTest.DISABLED_ROOT_DOCKER_SlaveRecoveryExecutorContainer:DockerContainerizerT
[jira] [Comment Edited] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366900#comment-17366900
]
Saad Ur Rahman edited comment on MESOS-10224 at 6/22/21, 12:10 AM:
---
Hi [~qianzhang], thanks for checking on this:
{code:java}
-
We cannot run any aufs tests because:
aufs is not supported on your systems
-
-
We cannot run any cgroups tests that require mounting
hierarchies because you have the following hierarchies mounted:
/sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu,cpuacct, /sys/fs/cgroup/cpuset,
/sys/fs/cgroup/devices, /sys/fs/cgroup/freezer, /sys/fs/cgroup/hugetlb,
/sys/fs/cgroup/memory, /sys/fs/cgroup/net_cls,net_prio,
/sys/fs/cgroup/perf_event, /sys/fs/cgroup/pids, /sys/fs/cgroup/rdma,
/sys/fs/cgroup/systemd
We'll disable the CgroupsNoHierarchyTest test fixture for now.
-
-
We cannot run any Docker tests because:
Failed to get docker version: Failed to execute 'docker -H
unix:///var/run/docker.sock --version': exited with status 127
-
PING google.com (172.217.165.14) 56(84) bytes of data.
64 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=1 ttl=115
time=5.62 ms--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.617/5.617/5.617/0.000 ms
# Warning: iptables-legacy tables present, use iptables-legacy to see them
-
We cannot run any overlayfs tests because:
overlayfs is not supported on your systems
-
E0621 19:40:00.390394 8397 perf.cpp:251] Failed to get perf version: Failed to
execute perf: exited with status 2
-
Could not find the 'perf' command or its version lower that 2.6.39 so tests
using it to sample the 'cpu-cycles' hardware event will not be run.
-
E0621 19:40:00.489571 8397 perf.cpp:251] Failed to get perf version: Failed to
execute perf: exited with status 2
-
require 'perf' version >= 2.6.39 so no 'perf' tests will be run
-
-
We can't run any VETH tests:
iproute2 version is not an integer
-
-
We cannot run any xfs tests because:
xfs is not supported on your systems
-
Note: Google Test filter =
LdcacheTest.Parse-DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthyTask:DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthStatusChange:DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthyTaskWithQuotedCommand:BENCHMARK_HierarchicalAllocations.MultiFrameworkAllocations:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerTaskExecutorDecorator:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerValidator:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerHook:HookTest.ROOT_DOCKER_VerifySlavePostFetchHook:Resources_Filter_BENCHMARK_Test.Filters:CommonSorterTest/0.BENCHMARK_FullSort:CommonSorterTest/0.BENCHMARK_HierarchyFullSort:CommonSorterTest/1.BENCHMARK_FullSort:CommonSorterTest/1.BENCHMARK_HierarchyFullSort:DockerContainerizerTest.ROOT_DOCKER_Launch_Executor:DockerContainerizerTest.DISABLED_ROOT_DOCKER_Launch_Executor_Bridged:DockerContainerizerTest.ROOT_DOCKER_Launch:DockerContainerizerTest.ROOT_DOCKER_MaxCompletionTime:DockerContainerizerTest.ROOT_DOCKER_Kill:DockerContainerizerTest.ROOT_DOCKER_TaskKillingCapability:DockerContainerizerTest.ROOT_DOCKER_Usage:DockerContainerizerTest.ROOT_DOCKER_Recover:DockerContainerizerTest.ROOT_DOCKER_KillOrphanContainers:DockerContainerizerTest.ROOT_DOCKER_SkipRecoverNonDocker:DockerContainerizerTest.ROOT_DOCKER_SkipRecoverMalformedUUID:DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_RecoverPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_RecoverOrphanedPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_Logs:DockerContainerizerTest.ROOT_DOCKER_Default_CMD:DockerContainerizerTest.ROOT_DOCKER_Default_CMD_Override:DockerContainerizerTest.ROOT_DOCKER_Default_CMD_Args:DockerContainerizerTest.ROOT_DOCKER_SlaveRecoveryTaskContainer:DockerContainerizerTest.DISABLED_ROOT_DOCKER_SlaveRecoveryExecutorContainer:DockerContainerizerT
[jira] [Commented] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
[
https://issues.apache.org/jira/browse/MESOS-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366900#comment-17366900
]
Saad Ur Rahman commented on MESOS-10224:
Hi [~qianzhang], thanks for checking on this:
{code:java}
-
We cannot run any aufs tests because:
aufs is not supported on your systems
-
-
We cannot run any cgroups tests that require mounting
hierarchies because you have the following hierarchies mounted:
/sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu,cpuacct, /sys/fs/cgroup/cpuset,
/sys/fs/cgroup/devices, /sys/fs/cgroup/freezer, /sys/fs/cgroup/hugetlb,
/sys/fs/cgroup/memory, /sys/fs/cgroup/net_cls,net_prio,
/sys/fs/cgroup/perf_event, /sys/fs/cgroup/pids, /sys/fs/cgroup/rdma,
/sys/fs/cgroup/systemd
We'll disable the CgroupsNoHierarchyTest test fixture for now.
-
-
We cannot run any Docker tests because:
Failed to get docker version: Failed to execute 'docker -H
unix:///var/run/docker.sock --version': exited with status 127
-
PING google.com (172.217.165.14) 56(84) bytes of data.
64 bytes from yyz12s06-in-f14.1e100.net (172.217.165.14): icmp_seq=1 ttl=115
time=5.62 ms--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.617/5.617/5.617/0.000 ms
# Warning: iptables-legacy tables present, use iptables-legacy to see them
-
We cannot run any overlayfs tests because:
overlayfs is not supported on your systems
-
E0621 19:40:00.390394 8397 perf.cpp:251] Failed to get perf version: Failed to
execute perf: exited with status 2
-
Could not find the 'perf' command or its version lower that 2.6.39 so tests
using it to sample the 'cpu-cycles' hardware event will not be run.
-
E0621 19:40:00.489571 8397 perf.cpp:251] Failed to get perf version: Failed to
execute perf: exited with status 2
-
require 'perf' version >= 2.6.39 so no 'perf' tests will be run
-
-
We can't run any VETH tests:
iproute2 version is not an integer
-
-
We cannot run any xfs tests because:
xfs is not supported on your systems
-
Note: Google Test filter =
LdcacheTest.Parse-DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthyTask:DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthStatusChange:DockerContainerizerHealthCheckTest.ROOT_DOCKER_DockerHealthyTaskWithQuotedCommand:BENCHMARK_HierarchicalAllocations.MultiFrameworkAllocations:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerTaskExecutorDecorator:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerValidator:HookTest.ROOT_DOCKER_VerifySlavePreLaunchDockerHook:HookTest.ROOT_DOCKER_VerifySlavePostFetchHook:Resources_Filter_BENCHMARK_Test.Filters:CommonSorterTest/0.BENCHMARK_FullSort:CommonSorterTest/0.BENCHMARK_HierarchyFullSort:CommonSorterTest/1.BENCHMARK_FullSort:CommonSorterTest/1.BENCHMARK_HierarchyFullSort:DockerContainerizerTest.ROOT_DOCKER_Launch_Executor:DockerContainerizerTest.DISABLED_ROOT_DOCKER_Launch_Executor_Bridged:DockerContainerizerTest.ROOT_DOCKER_Launch:DockerContainerizerTest.ROOT_DOCKER_MaxCompletionTime:DockerContainerizerTest.ROOT_DOCKER_Kill:DockerContainerizerTest.ROOT_DOCKER_TaskKillingCapability:DockerContainerizerTest.ROOT_DOCKER_Usage:DockerContainerizerTest.ROOT_DOCKER_Recover:DockerContainerizerTest.ROOT_DOCKER_KillOrphanContainers:DockerContainerizerTest.ROOT_DOCKER_SkipRecoverNonDocker:DockerContainerizerTest.ROOT_DOCKER_SkipRecoverMalformedUUID:DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_RecoverPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_RecoverOrphanedPersistentVolumes:DockerContainerizerTest.ROOT_DOCKER_Logs:DockerContainerizerTest.ROOT_DOCKER_Default_CMD:DockerContainerizerTest.ROOT_DOCKER_Default_CMD_Override:DockerContainerizerTest.ROOT_DOCKER_Default_CMD_Args:DockerContainerizerTest.ROOT_DOCKER_SlaveRecoveryTaskContainer:DockerContainerizerTest.DISABLED_ROOT_DOCKER_SlaveRecoveryExecutorContainer:DockerContainerizerTest.ROOT_DOCKER_NC_PortMapping:DockerContainerizerTes
[jira] [Created] (MESOS-10224) [test] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
Saad Ur Rahman created MESOS-10224:
--
Summary: [test]
CSIVersion/StorageLocalResourceProviderTest.OperationUpdate fails.
Key: MESOS-10224
URL: https://issues.apache.org/jira/browse/MESOS-10224
Project: Mesos
Issue Type: Bug
Components: test
Affects Versions: 1.11.0
Reporter: Saad Ur Rahman
*OS:* Ubuntu 21.04
*Command:*
{code:java}
make -j 6 V=0 check{code}
Fails during the build and test suite run on two different machines with the
same OS.
{code:java}
3: [ OK ] CSIVersion/StorageLocalResourceProviderTest.Update/v0 (479 ms)
3: [--] 14 tests from CSIVersion/StorageLocalResourceProviderTest
(27011 ms total)
3:
3: [--] Global test environment tear-down
3: [==] 575 tests from 178 test cases ran. (202572 ms total)
3: [ PASSED ] 573 tests.
3: [ FAILED ] 2 tests, listed below:
3: [ FAILED ] LdcacheTest.Parse
3: [ FAILED ] CSIVersion/StorageLocalResourceProviderTest.OperationUpdate/v0,
where GetParam() = "v0"
3:
3: 2 FAILED TESTS
3: YOU HAVE 34 DISABLED TESTS
3:
3:
3:
3: [FAIL]: 4 shard(s) have failed tests
3/3 Test #3: MesosTests ...***Failed 1173.43 sec
{code}
Are there any pre-requisites required to get the build/tests to pass? I am
trying to get all the tests to pass to make sure my build environment is setup
correctly for development.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MESOS-9713) Support specifying output file name for URI fetcher
[
https://issues.apache.org/jira/browse/MESOS-9713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365091#comment-17365091
]
Saad Ur Rahman commented on MESOS-9713:
---
[~cf.natali], thanks for the confirmation!
I am looking for newbie/noob issues to work on so I can better understand the
codebase. My background is Distributed and Data Systems and Matei Z. is from my
alma mater, so this project is interesting to me. I am looking to learn,
sharpen my skill set, and use that effort to do something useful.
> Support specifying output file name for URI fetcher
> ---
>
> Key: MESOS-9713
> URL: https://issues.apache.org/jira/browse/MESOS-9713
> Project: Mesos
> Issue Type: Improvement
> Components: fetcher
>Reporter: Qian Zhang
>Priority: Major
> Labels: newbie
>
> Currently URI fetcher's `fetch` method is defined like below:
> {code:java}
> process::Future fetch(
> const URI& uri,
> const std::string& directory,
> const Option& data = None()) const;
> {code}
> So caller can only specify the directory that the URI will be downloaded to
> but not the name of the output file which has to be same with base name of
> the URI path. We'd better to introduce an output file name parameter so that
> caller can customize the output file name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MESOS-9713) Support specifying output file name for URI fetcher
[
https://issues.apache.org/jira/browse/MESOS-9713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364430#comment-17364430
]
Saad Ur Rahman edited comment on MESOS-9713 at 6/17/21, 2:29 AM:
-
I would like to work on this issue if no one else is? I shall look over the
code and write up a plan of action before beginning to work on it.
_*Edit:*_ From the commit diffs in the related issues this seems to have been
patched, am I correct?
was (Author: surahman):
I would like to work on this issue if no one else is? I shall look over the
code and write up a plan of action before beginning to work on it.
> Support specifying output file name for URI fetcher
> ---
>
> Key: MESOS-9713
> URL: https://issues.apache.org/jira/browse/MESOS-9713
> Project: Mesos
> Issue Type: Improvement
> Components: fetcher
>Reporter: Qian Zhang
>Priority: Major
> Labels: newbie
>
> Currently URI fetcher's `fetch` method is defined like below:
> {code:java}
> process::Future fetch(
> const URI& uri,
> const std::string& directory,
> const Option& data = None()) const;
> {code}
> So caller can only specify the directory that the URI will be downloaded to
> but not the name of the output file which has to be same with base name of
> the URI path. We'd better to introduce an output file name parameter so that
> caller can customize the output file name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MESOS-9713) Support specifying output file name for URI fetcher
[
https://issues.apache.org/jira/browse/MESOS-9713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364430#comment-17364430
]
Saad Ur Rahman commented on MESOS-9713:
---
I would like to work on this issue if no one else is? I shall look over the
code and write up a plan of action before beginning to work on it.
> Support specifying output file name for URI fetcher
> ---
>
> Key: MESOS-9713
> URL: https://issues.apache.org/jira/browse/MESOS-9713
> Project: Mesos
> Issue Type: Improvement
> Components: fetcher
>Reporter: Qian Zhang
>Priority: Major
> Labels: newbie
>
> Currently URI fetcher's `fetch` method is defined like below:
> {code:java}
> process::Future fetch(
> const URI& uri,
> const std::string& directory,
> const Option& data = None()) const;
> {code}
> So caller can only specify the directory that the URI will be downloaded to
> but not the name of the output file which has to be same with base name of
> the URI path. We'd better to introduce an output file name parameter so that
> caller can customize the output file name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
