[jira] [Commented] (MESOS-9529) `/proc` should be remounted even if a nested container set `share_pid_namespace` to true
[ https://issues.apache.org/jira/browse/MESOS-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809399#comment-16809399 ] Jie Yu commented on MESOS-9529: --- commit f0b6a5568cc5573be8f0ac5f9dcdd48914b5 (HEAD -> master, origin/master, origin/HEAD, proc) Author: Jie Yu Date: Mon Apr 1 18:17:21 2019 -0700 Mounted /proc properly a container shares pid namespace with its parent. If a container shares the same pid namespace as its parent and is not a top level container. It might or might not share the same pid namespace as the agent. In this case, we need to re-mount `/proc`. One caveat here is that: in the case where this container does share the pid namespace of the agent (because its parent shares the same pid namespace of the agent), mounting `/proc` at the same place will result in EBUSY. As a result, we need to "move" (MS_MOVE) the mounts under `/proc` to a new location and mount the `/proc` again at the old location. See MESOS-9529 for details. Review: https://reviews.apache.org/r/70356 commit 76e583ab6ba71e7aef020fc662c0c36d6f3d9923 Author: Jie Yu Date: Mon Apr 1 18:11:59 2019 -0700 Switched to used `/proc/1/ns/pid` to test pid namespaces. Previously, we're using `/proc/self/ns/pid` to test pid namespaces. This is proven to be problematic because the kernel will resolve correctly even if the `/proc` is not re-mounted in the new pid namespace. Review: https://reviews.apache.org/r/70355 > `/proc` should be remounted even if a nested container set > `share_pid_namespace` to true > > > Key: MESOS-9529 > URL: https://issues.apache.org/jira/browse/MESOS-9529 > Project: Mesos > Issue Type: Bug > Components: containerization >Affects Versions: 1.4.2, 1.5.2, 1.6.2, 1.7.1 >Reporter: Jie Yu >Assignee: Jie Yu >Priority: Critical > > Currently, if a nested container wants to share the pid namespace of its > parent container, we allow the framework to set > `LinuxInfo.share_pid_namespace`. > If the nested container does not have its own rootfs (i.e., using the host > rootfs), the `/proc` is not re-mounted: > https://github.com/apache/mesos/blob/1.7.x/src/slave/containerizer/mesos/isolators/namespaces/pid.cpp#L120-L126 > This is problematic because the nested container will fork host's mount > namespace, thus inherit the `/proc` there. As a result, `/proc/` are > still for the host pid namespace. The pid namespace of the parent container > might be different than that of the host pid namspace. > As a result, `ps aux` in the nested container will show all process > information on the host pid namespace. Although, the pid namespace of the > nested container is different than that of the host. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-9635) OperationReconciliationTest.AgentPendingOperationAfterMasterFailover is flaky again (3x) due to orphan operations
[
https://issues.apache.org/jira/browse/MESOS-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Mann reassigned MESOS-9635:
Assignee: Greg Mann (was: Gastón Kleiman)
> OperationReconciliationTest.AgentPendingOperationAfterMasterFailover is flaky
> again (3x) due to orphan operations
> -
>
> Key: MESOS-9635
> URL: https://issues.apache.org/jira/browse/MESOS-9635
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Benno Evers
>Assignee: Greg Mann
>Priority: Blocker
> Labels: foundations, mesosphere
> Attachments: failure
>
>
> This test fails consistently when run while the system is stressed:
> {code}
> [ RUN ]
> ContentType/OperationReconciliationTest.AgentPendingOperationAfterMasterFailover/0
> F0305 08:10:07.670622 3982 hierarchical.cpp:1259] Check failed:
> slave.getAllocated().contains(resources) {} does not contain disk(allocated:
> default-role)[RAW(,,profile)]:200
> *** Check failure stack trace: ***
> @ 0x7f1120b0ce5e google::LogMessage::Fail()
> @ 0x7f1120b0cdbb google::LogMessage::SendToLog()
> @ 0x7f1120b0c7b5 google::LogMessage::Flush()
> @ 0x7f1120b0f578 google::LogMessageFatal::~LogMessageFatal()
> @ 0x7f111e536f2a
> mesos::internal::master::allocator::internal::HierarchicalAllocatorProcess::recoverResources()
> @ 0x5580c2651c26
> _ZZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS1_11FrameworkIDERKNS1_7SlaveIDERKNS1_9ResourcesERK6OptionINS1_7FiltersEES8_SB_SE_SJ_EEvRKNS_3PIDIT_EEMSL_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_ENKUlOS6_OS9_OSC_OSH_PNS_11ProcessBaseEE_clES13_S14_S15_S16_S18_
> @ 0x5580c26c7e02
> _ZN5cpp176invokeIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS3_11FrameworkIDERKNS3_7SlaveIDERKNS3_9ResourcesERK6OptionINS3_7FiltersEESA_SD_SG_SL_EEvRKNS1_3PIDIT_EEMSN_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOS8_OSB_OSE_OSJ_PNS1_11ProcessBaseEE_JS8_SB_SE_SJ_S1A_EEEDTclcl7forwardISN_Efp_Espcl7forwardIT0_Efp0_EEEOSN_DpOS1C_
> @ 0x5580c26c5b1e
> _ZN6lambda8internal7PartialIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS4_11FrameworkIDERKNS4_7SlaveIDERKNS4_9ResourcesERK6OptionINS4_7FiltersEESB_SE_SH_SM_EEvRKNS2_3PIDIT_EEMSO_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOS9_OSC_OSF_OSK_PNS2_11ProcessBaseEE_JS9_SC_SF_SK_St12_PlaceholderILi113invoke_expandIS1C_St5tupleIJS9_SC_SF_SK_S1E_EES1H_IJOS1B_EEJLm0ELm1ELm2ELm3ELm4DTcl6invokecl7forwardISO_Efp_Espcl6expandcl3getIXT2_EEcl7forwardISS_Efp0_EEcl7forwardIST_Efp2_OSO_OSS_N5cpp1416integer_sequenceImJXspT2_OST_
> @ 0x5580c26c47ac
> _ZNO6lambda8internal7PartialIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS4_11FrameworkIDERKNS4_7SlaveIDERKNS4_9ResourcesERK6OptionINS4_7FiltersEESB_SE_SH_SM_EEvRKNS2_3PIDIT_EEMSO_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOS9_OSC_OSF_OSK_PNS2_11ProcessBaseEE_JS9_SC_SF_SK_St12_PlaceholderILi1clIJS1B_EEEDTcl13invoke_expandcl4movedtdefpT1fEcl4movedtdefpT10bound_argsEcvN5cpp1416integer_sequenceImJLm0ELm1ELm2ELm3ELm4_Ecl16forward_as_tuplespcl7forwardIT_Efp_DpOS1K_
> @ 0x5580c26c3ad7
> _ZN5cpp176invokeIN6lambda8internal7PartialIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS6_11FrameworkIDERKNS6_7SlaveIDERKNS6_9ResourcesERK6OptionINS6_7FiltersEESD_SG_SJ_SO_EEvRKNS4_3PIDIT_EEMSQ_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOSB_OSE_OSH_OSM_PNS4_11ProcessBaseEE_JSB_SE_SH_SM_St12_PlaceholderILi1EJS1D_EEEDTclcl7forwardISQ_Efp_Espcl7forwardIT0_Efp0_EEEOSQ_DpOS1I_
> @ 0x5580c26c32ad
> _ZN6lambda8internal6InvokeIvEclINS0_7PartialIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS7_11FrameworkIDERKNS7_7SlaveIDERKNS7_9ResourcesERK6OptionINS7_7FiltersEESE_SH_SK_SP_EEvRKNS5_3PIDIT_EEMSR_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOSC_OSF_OSI_OSN_PNS5_11ProcessBaseEE_JSC_SF_SI_SN_St12_PlaceholderILi1EJS1E_EEEvOSR_DpOT0_
> @ 0x5580c26c0a5e
> _ZNO6lambda12CallableOnceIFvPN7process11ProcessBaseEEE10CallableFnINS_8internal7PartialIZNS1_8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNSA_11FrameworkIDERKNSA_7SlaveIDERKNSA_9ResourcesERK6OptionINSA_7FiltersEESH_SK_SN_SS_EEvRKNS1_3PIDIT_EEMSU_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOSF_OSI_OSL_OSQ_S3_E_JSF_SI_SL_SQ_St12_PlaceholderILi1EEclEOS3_
> @ 0x7f1120a51c60
> _ZNO6lambda12CallableOnceIFvPN7process11ProcessBaseEEEclES3_
> @ 0x7f1120a16a4e process::ProcessBase::consume()
> @ 0x7f1120a3d9d8
> _ZNO7process13DispatchEvent7consumeEPNS_13EventConsumerE
> @ 0x5580c2284afa process::ProcessBase::serve()
> @
[jira] [Comment Edited] (MESOS-9635) OperationReconciliationTest.AgentPendingOperationAfterMasterFailover is flaky again (3x) due to orphan operations
[
https://issues.apache.org/jira/browse/MESOS-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16803066#comment-16803066
]
Greg Mann edited comment on MESOS-9635 at 4/4/19 12:11 AM:
---
I think this issue would be better addressed by allocating the recovered orphan
operations at the time of framework recovery, rather than when an
{{UpdateSlaveMessage}} is received. The following patch implements this
approach:
https://reviews.apache.org/r/70325/
was (Author: greggomann):
I think this issue would be better addressed by allocating the recovered orphan
operations at the time of framework recovery, rather than when an
{{UpdateSlaveMessage}} is received. The following patches implement this
approach:
https://reviews.apache.org/r/70324/
https://reviews.apache.org/r/70325/
> OperationReconciliationTest.AgentPendingOperationAfterMasterFailover is flaky
> again (3x) due to orphan operations
> -
>
> Key: MESOS-9635
> URL: https://issues.apache.org/jira/browse/MESOS-9635
> Project: Mesos
> Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Benno Evers
>Assignee: Gastón Kleiman
>Priority: Blocker
> Labels: foundations, mesosphere
> Attachments: failure
>
>
> This test fails consistently when run while the system is stressed:
> {code}
> [ RUN ]
> ContentType/OperationReconciliationTest.AgentPendingOperationAfterMasterFailover/0
> F0305 08:10:07.670622 3982 hierarchical.cpp:1259] Check failed:
> slave.getAllocated().contains(resources) {} does not contain disk(allocated:
> default-role)[RAW(,,profile)]:200
> *** Check failure stack trace: ***
> @ 0x7f1120b0ce5e google::LogMessage::Fail()
> @ 0x7f1120b0cdbb google::LogMessage::SendToLog()
> @ 0x7f1120b0c7b5 google::LogMessage::Flush()
> @ 0x7f1120b0f578 google::LogMessageFatal::~LogMessageFatal()
> @ 0x7f111e536f2a
> mesos::internal::master::allocator::internal::HierarchicalAllocatorProcess::recoverResources()
> @ 0x5580c2651c26
> _ZZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS1_11FrameworkIDERKNS1_7SlaveIDERKNS1_9ResourcesERK6OptionINS1_7FiltersEES8_SB_SE_SJ_EEvRKNS_3PIDIT_EEMSL_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_ENKUlOS6_OS9_OSC_OSH_PNS_11ProcessBaseEE_clES13_S14_S15_S16_S18_
> @ 0x5580c26c7e02
> _ZN5cpp176invokeIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS3_11FrameworkIDERKNS3_7SlaveIDERKNS3_9ResourcesERK6OptionINS3_7FiltersEESA_SD_SG_SL_EEvRKNS1_3PIDIT_EEMSN_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOS8_OSB_OSE_OSJ_PNS1_11ProcessBaseEE_JS8_SB_SE_SJ_S1A_EEEDTclcl7forwardISN_Efp_Espcl7forwardIT0_Efp0_EEEOSN_DpOS1C_
> @ 0x5580c26c5b1e
> _ZN6lambda8internal7PartialIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS4_11FrameworkIDERKNS4_7SlaveIDERKNS4_9ResourcesERK6OptionINS4_7FiltersEESB_SE_SH_SM_EEvRKNS2_3PIDIT_EEMSO_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOS9_OSC_OSF_OSK_PNS2_11ProcessBaseEE_JS9_SC_SF_SK_St12_PlaceholderILi113invoke_expandIS1C_St5tupleIJS9_SC_SF_SK_S1E_EES1H_IJOS1B_EEJLm0ELm1ELm2ELm3ELm4DTcl6invokecl7forwardISO_Efp_Espcl6expandcl3getIXT2_EEcl7forwardISS_Efp0_EEcl7forwardIST_Efp2_OSO_OSS_N5cpp1416integer_sequenceImJXspT2_OST_
> @ 0x5580c26c47ac
> _ZNO6lambda8internal7PartialIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS4_11FrameworkIDERKNS4_7SlaveIDERKNS4_9ResourcesERK6OptionINS4_7FiltersEESB_SE_SH_SM_EEvRKNS2_3PIDIT_EEMSO_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOS9_OSC_OSF_OSK_PNS2_11ProcessBaseEE_JS9_SC_SF_SK_St12_PlaceholderILi1clIJS1B_EEEDTcl13invoke_expandcl4movedtdefpT1fEcl4movedtdefpT10bound_argsEcvN5cpp1416integer_sequenceImJLm0ELm1ELm2ELm3ELm4_Ecl16forward_as_tuplespcl7forwardIT_Efp_DpOS1K_
> @ 0x5580c26c3ad7
> _ZN5cpp176invokeIN6lambda8internal7PartialIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS6_11FrameworkIDERKNS6_7SlaveIDERKNS6_9ResourcesERK6OptionINS6_7FiltersEESD_SG_SJ_SO_EEvRKNS4_3PIDIT_EEMSQ_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOSB_OSE_OSH_OSM_PNS4_11ProcessBaseEE_JSB_SE_SH_SM_St12_PlaceholderILi1EJS1D_EEEDTclcl7forwardISQ_Efp_Espcl7forwardIT0_Efp0_EEEOSQ_DpOS1I_
> @ 0x5580c26c32ad
> _ZN6lambda8internal6InvokeIvEclINS0_7PartialIZN7process8dispatchIN5mesos8internal6master9allocator21MesosAllocatorProcessERKNS7_11FrameworkIDERKNS7_7SlaveIDERKNS7_9ResourcesERK6OptionINS7_7FiltersEESE_SH_SK_SP_EEvRKNS5_3PIDIT_EEMSR_FvT0_T1_T2_T3_EOT4_OT5_OT6_OT7_EUlOSC_OSF_OSI_OSN_PNS5_11ProcessBaseEE_JSC_SF_SI_SN_St12_PlaceholderILi1EJS1E_EEEvOSR_DpOT0_
> @ 0x5580c26c0a5e
>
[jira] [Commented] (MESOS-9624) Bundle CSI spec v1.0 in Mesos.
[
https://issues.apache.org/jira/browse/MESOS-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809359#comment-16809359
]
Chun-Hung Hsiao commented on MESOS-9624:
Committed the following changes first:
{noformat}
commit 4fc6ceba906d4e726c6c9d1ebd94ece152f2cf57
Author: Chun-Hung Hsiao
Date: Mon Apr 1 23:24:05 2019 -0700
Adjusted CSI v0 bundling and proto compilation.
This patch makes the following adjustments so we can build CSI v0 and v1
in the future:
* Standardize placements for third-party proto files: `csi.proto` from
CSI v0 should be in `csi/v0/` of the library root directory and that
from v1 should be in `csi/v1/` in the future. Dependent proto files
should import `csi/v0/csi.proto` or `csi/v1/csi.proto`.
* The generated files for CSI v0 is placed in `build/include/csi/v0`,
and those for CSI v1 will be in `build/include/csi/v1` in the future.
* Moved `include/csi/spec.hpp` to `include/mesos/csi/v0.hpp`. In the
future, CSI v1 proto headers will be in `include/mesos/csi/v1.hpp`.
* Install the CSI v0 proto file and its generated headers to
`$PREFIX/include/csi/v0` in autotools. CSI v1 files will be installed
at `$PREFIX/include/csi/v1` in the future.
Review: https://reviews.apache.org/r/70302/{noformat}
{noformat}
commit 35e57187b885afa87210c7d66e1dd43c08eded99
Author: Chun-Hung Hsiao
Date: Mon Mar 25 18:16:21 2019 -0700
Moved CSI v0 type helpers to the `mesos/csi/v0.hpp` header.
The equality check and output helpers for CSI v0 protobufs are now
declared in the `v0.hpp` header to ensure ADL works properly. The
implementation is also moved to a new `v0.cpp` file.
The header and implementation files for CSI v0 utility helpers are also
renamed for future CSI v1 support.
Review: https://reviews.apache.org/r/70303{noformat}
> Bundle CSI spec v1.0 in Mesos.
> --
>
> Key: MESOS-9624
> URL: https://issues.apache.org/jira/browse/MESOS-9624
> Project: Mesos
> Issue Type: Task
> Components: storage
>Reporter: Chun-Hung Hsiao
>Assignee: Chun-Hung Hsiao
>Priority: Critical
> Labels: mesosphere, storage
>
> We need to bundle both CSI v0 and v1 in Mesos. This requires some redesign of
> the source code filesystem layout.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-9623) Implement CSI volume manager with CSI v1.
[
https://issues.apache.org/jira/browse/MESOS-9623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809358#comment-16809358
]
Chun-Hung Hsiao commented on MESOS-9623:
Committed the following changes first:
{noformat}
commit f728ce3b5014993db54d5bf6472fcecb3c098934 (HEAD -> tmp, upstream/master)
Author: Chun-Hung Hsiao
Date: Mon Mar 25 21:34:02 2019 -0700
Cleaned up `mesos::csi::v0::Client` interface.
Since per-CSI-call metrics are no longer implemented, there is very less
value to keep the `mesos::csi::v0::RPC` enum, which is tightly coupled
with `mesos::csi::v0::Client`. Therefore, the enum and its header are
removed.
The header and implementation file for `mesos::csi::v0::Client` is also
renamed for future CSI v1 support.
Review: https://reviews.apache.org/r/70321{noformat}
> Implement CSI volume manager with CSI v1.
> -
>
> Key: MESOS-9623
> URL: https://issues.apache.org/jira/browse/MESOS-9623
> Project: Mesos
> Issue Type: Task
> Components: storage
>Reporter: Chun-Hung Hsiao
>Assignee: Chun-Hung Hsiao
>Priority: Critical
> Labels: mesosphere, storage
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-9696) Test MasterQuotaTest.AvailableResourcesSingleDisconnectedAgent is flaky
[
https://issues.apache.org/jira/browse/MESOS-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler reassigned MESOS-9696:
--
Assignee: Benjamin Mahler
> Test MasterQuotaTest.AvailableResourcesSingleDisconnectedAgent is flaky
> ---
>
> Key: MESOS-9696
> URL: https://issues.apache.org/jira/browse/MESOS-9696
> Project: Mesos
> Issue Type: Bug
> Components: test
>Affects Versions: 1.8.0
>Reporter: Benjamin Bannier
>Assignee: Benjamin Mahler
>Priority: Major
> Labels: flaky, flaky-test, resource-management
> Attachments: test.log
>
>
> The test {{MasterQuotaTest.AvailableResourcesSingleDisconnectedAgent}} is
> flaky, especially under additional system load.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-9691) Quota headroom calculation is off when subroles are involved.
[
https://issues.apache.org/jira/browse/MESOS-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler reassigned MESOS-9691:
--
Assignee: Benjamin Mahler
> Quota headroom calculation is off when subroles are involved.
> -
>
> Key: MESOS-9691
> URL: https://issues.apache.org/jira/browse/MESOS-9691
> Project: Mesos
> Issue Type: Bug
> Components: allocation
>Reporter: Meng Zhu
>Assignee: Benjamin Mahler
>Priority: Critical
> Labels: resource-management
>
> Quota "availableHeadroom" calculation:
> https://github.com/apache/mesos/blob/6276f7e73b0dbe7df49a7315cd1b83340d66f4ea/src/master/allocator/mesos/hierarchical.cpp#L1751-L1754
> is off when subroles are involved.
> Specifically, in the formula
> {noformat}
> available headroom = total resources - allocated resources - (total
> reservations - allocated reservations) - unallocated revocable resources
> {noformat}
> The "allocated resources" part is hierarchical-aware and aggregate that
> across all roles, thus allocations to subroles will be counted multiple times
> (in the case of "a/b", once for "a" and once for "a/b").
> The "total reservations" is correct, since today it is "flat" (reservations
> made to "a/b" are not counted to "a"). Thus all reservations are only counted
> once -- which is the correct semantic here. However, once we fix MESOS-9688
> (which likely requires reservation tracking to be hierarchical-aware), we
> need to ensure that the accounting is still correct.
> The "allocated reservations" is hierarchical-aware, thus overlap accounting
> would occur.
> Basically, when calculating the available headroom, we need to ensure
> "single-counting". Ideally, we only need to look at the root's consumptions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-9688) Quota is not enforced properly when subroles have reservations.
[
https://issues.apache.org/jira/browse/MESOS-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler reassigned MESOS-9688:
--
Assignee: Benjamin Mahler
> Quota is not enforced properly when subroles have reservations.
> ---
>
> Key: MESOS-9688
> URL: https://issues.apache.org/jira/browse/MESOS-9688
> Project: Mesos
> Issue Type: Bug
> Components: allocation
>Reporter: Meng Zhu
>Assignee: Benjamin Mahler
>Priority: Critical
> Labels: resource-management
>
> Note: the discussion here concerns quota enforcement for top-level role,
> setting quota on sublevel role is not supported.
> If a subrole directly makes a reservation, the accounting of
> `roleConsumedQuota` will be off:
> https://github.com/apache/mesos/blob/master/src/master/allocator/mesos/hierarchical.cpp#L1703-L1705
> Specifically, in this formula:
> `Consumed Quota = reservations + allocation - allocated reservations`
> The `reservations` part does not account subrole's reservation to its
> ancestors. If a reservation is made directly for role "a/b", its reservation
> is accounted only for "a/b" but not for "a". Similarly, if a top role ( "a")
> reservation is refined to a subrole ("a/b"), the current code first subtracts
> the reservation from "a" and then track that under "a/b".
> We should make it hierarchical-aware.
> The "allocation" and "allocated reservations" are both tracked in the sorter
> where the hierarchical relationship is considered -- allocations are added
> hierarchically.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-7974) Accept "application/recordio" type is rejected for master operator API SUBSCRIBE call
[ https://issues.apache.org/jira/browse/MESOS-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808914#comment-16808914 ] Benno Evers commented on MESOS-7974: Re-targeted to 1.9.0. > Accept "application/recordio" type is rejected for master operator API > SUBSCRIBE call > - > > Key: MESOS-7974 > URL: https://issues.apache.org/jira/browse/MESOS-7974 > Project: Mesos > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: James DeFelice >Assignee: Joseph Wu >Priority: Major > Labels: mesosphere > > The agent operator API supports for "application/recordio" for things like > attach-container-output, which streams objects back to the caller. I expected > the master operator API SUBSCRIBE call to work the same way, w/ > Accept/Content-Type headers for "recordio" and > Message-Accept/Message-Content-Type headers for json (or protobuf). This was > not the case. > Looking again at the master operator API documentation, SUBSCRIBE docs > illustrate usage Accept and Content-Type headers for the "application/json" > type. Not a "recordio" type. So my experience, as per the docs, seems > expected. However, this is counter-intuitive since the whole point of adding > the new Message-prefixed headers was to help callers consistently request > (and differentiate) streaming responses from non-streaming responses in the > v1 API. > Please fix the master operator API implementation to also support the > Message-prefixed headers w/ Accept/Content-Type set to "recordio". > Observed on ubuntu w/ mesos package version 1.2.1-2.0.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MESOS-9082) Avoid two trips through the master mailbox for state.json requests.
[
https://issues.apache.org/jira/browse/MESOS-9082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benno Evers reassigned MESOS-9082:
--
Assignee: (was: Benno Evers)
> Avoid two trips through the master mailbox for state.json requests.
> ---
>
> Key: MESOS-9082
> URL: https://issues.apache.org/jira/browse/MESOS-9082
> Project: Mesos
> Issue Type: Task
>Reporter: Alexander Rukletsov
>Priority: Major
> Labels: foundations, mesosphere, performance
>
> Currently, a state.json request travels through the master's mailbox twice:
> before authorization and after. This increases the overall state.json
> response time by around 30%.
> To remove one mailbox trip, we can perform the initial portion (validation
> and authorization) of state and /state off the master actor by using a
> top-level {{Route}}, then dispatch onto the master actor only for json /
> protobuf serialization. This should drop the authorization time down to near
> 0 if it's indeed mostly queuing delay.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (MESOS-8148) Enforce text attribute value specification for zone and region values
[
https://issues.apache.org/jira/browse/MESOS-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benno Evers reassigned MESOS-8148:
--
Assignee: (was: Benno Evers)
> Enforce text attribute value specification for zone and region values
> -
>
> Key: MESOS-8148
> URL: https://issues.apache.org/jira/browse/MESOS-8148
> Project: Mesos
> Issue Type: Improvement
>Reporter: Tim Harper
>Priority: Major
>
> Mesos has a specification for characters allowed by attribute values:
> http://mesos.apache.org/documentation/latest/attributes-resources/
> The specification is as follows:
> {code}
> scalar : floatValue
> floatValue : ( intValue ( "." intValue )? ) | ...
> intValue : [0-9]+
> range : "[" rangeValue ( "," rangeValue )* "]"
> rangeValue : scalar "-" scalar
> set : "{" text ( "," text )* "}"
> text : [a-zA-Z0-9_/.-]
> {code}
> Marathon is [implementing IN and IS
> constraints|https://docs.google.com/document/d/e/2PACX-1vSFvPol0pcHC2Web7EaNU0oSDS5wrOWSgFcmuslYBtISV2NB2JZ_D-B4wpWy_Vutaf08m2LX6WZVy6s/pub],
> and includes plans to support further attribute types as it makes sense to
> do so (IE {{a,b IS b,a}}, {{5 IN [0-10]}}). In order
> to do this, Marathon has adopted the Mesos attribute value specification and
> will enforce it in the validation layer. As an example, it will be possible
> to write things like:
> {code:java}
> "constraints": [
> ["attribute", "IN", "{value-a,value-b,value-c}"]
> ]
> {code}
> Additionally, Marathon allows one to specify constraints on non-attribute
> properties, such as region, hostname, or zone. If somebody specified a zone
> value with a comma, then the user would not be able to use the Mesos set
> value type specification to describe a set of zones in which an app should be
> deployed, and, as a consequence, would result in additional complexity (IE:
> Marathon would need to implement an escaping mechanism for this case).
> Ideally, the character space is confined to begin with. It the text type
> specification is sufficient, then, it seems simpler to re-use it rather than
> create another one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-7523) Whitelist devices in bulk on a per-container basis
[
https://issues.apache.org/jira/browse/MESOS-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808606#comment-16808606
]
James DeFelice commented on MESOS-7523:
---
Yes, still relevant. But the need is more along the lines of "some kinds of
privileged containers need access to the entire devices tree". Or, in other
words, the "devices" cgroup settings should allow some kinds of privileged
containers full access to /dev. There are multiple people that have asked for
this and the current workarounds are quite ugly (and not very secure).
> Whitelist devices in bulk on a per-container basis
> --
>
> Key: MESOS-7523
> URL: https://issues.apache.org/jira/browse/MESOS-7523
> Project: Mesos
> Issue Type: Improvement
>Reporter: James DeFelice
>Priority: Major
> Labels: containerization, csi-post-mvp, mesosphere,
> mesosphere-dss-post-ga, storage
>
> Continuation of the work in MESOS-6791
> It should be possible to whitelist a range (R) of devices such that R may be
> exposed to a container launched by an agent. Not all containers should have
> access to R by default, only those containers whose ContainerInfo specifies
> such access.
> For example, it may be useful to whitelist the range of devices matching the
> glob expressions `/dev/\{s,h,xv}d\[a-z]*` and `/dev/dm-\*` and
> `/dev/mapper/\*` for a container that intends to manage storage devices.
> /cc [~jieyu]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MESOS-6851) make install fails the second time
[
https://issues.apache.org/jira/browse/MESOS-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808554#comment-16808554
]
Benjamin Bannier edited comment on MESOS-6851 at 4/3/19 9:51 AM:
-
I am not aware of any, no.
You might be able to better track your installed packages with e.g.,
[checkinstall|http://checkinstall.izto.org/] which is superior to naked {{make
install}}.
was (Author: bbannier):
I am not aware of any, no.
You might be able to better track your installed packages with e.g.,
[checkinstall|[http://checkinstall.izto.org/]] which is superior to naked
{{make install}}.
> make install fails the second time
> --
>
> Key: MESOS-6851
> URL: https://issues.apache.org/jira/browse/MESOS-6851
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: James Peach
>Priority: Major
>
> Run {{make install}} twice and the second time will fail when it tries to
> overwrite symlinks:
> {code}
> make[4]: Entering directory '/home/jpeach/upstream/mesos/build/src'
> cd //opt/mesos/etc/mesos && \
> ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
> ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
> Makefile:12952: recipe for target 'copy-template-and-create-symlink' failed
> make[4]: *** [copy-template-and-create-symlink] Error 1
> make[4]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12487: recipe for target 'install-data-am' failed
> make[3]: *** [install-data-am] Error 2
> make[3]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12197: recipe for target 'install-am' failed
> make[2]: *** [install-am] Error 2
> make[2]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12191: recipe for target 'install' failed
> make[1]: *** [install] Error 2
> make[1]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:764: recipe for target 'install-recursive' failed
> make: *** [install-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-6851) make install fails the second time
[
https://issues.apache.org/jira/browse/MESOS-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808554#comment-16808554
]
Benjamin Bannier commented on MESOS-6851:
-
I am not aware of any, no.
You might be able to better track your installed packages with e.g.,
[checkinstall|[http://checkinstall.izto.org/]] which is superior to naked
{{make install}}.
> make install fails the second time
> --
>
> Key: MESOS-6851
> URL: https://issues.apache.org/jira/browse/MESOS-6851
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: James Peach
>Priority: Major
>
> Run {{make install}} twice and the second time will fail when it tries to
> overwrite symlinks:
> {code}
> make[4]: Entering directory '/home/jpeach/upstream/mesos/build/src'
> cd //opt/mesos/etc/mesos && \
> ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
> ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
> Makefile:12952: recipe for target 'copy-template-and-create-symlink' failed
> make[4]: *** [copy-template-and-create-symlink] Error 1
> make[4]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12487: recipe for target 'install-data-am' failed
> make[3]: *** [install-data-am] Error 2
> make[3]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12197: recipe for target 'install-am' failed
> make[2]: *** [install-am] Error 2
> make[2]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12191: recipe for target 'install' failed
> make[1]: *** [install] Error 2
> make[1]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:764: recipe for target 'install-recursive' failed
> make: *** [install-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-6851) make install fails the second time
[
https://issues.apache.org/jira/browse/MESOS-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808550#comment-16808550
]
Jorge Machado commented on MESOS-6851:
--
ah nice link. I see that the first one is for Centos anyone for ubuntu 18.04 ?
Mesosphere only has for ubuntu 16.04
> make install fails the second time
> --
>
> Key: MESOS-6851
> URL: https://issues.apache.org/jira/browse/MESOS-6851
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: James Peach
>Priority: Major
>
> Run {{make install}} twice and the second time will fail when it tries to
> overwrite symlinks:
> {code}
> make[4]: Entering directory '/home/jpeach/upstream/mesos/build/src'
> cd //opt/mesos/etc/mesos && \
> ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
> ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
> Makefile:12952: recipe for target 'copy-template-and-create-symlink' failed
> make[4]: *** [copy-template-and-create-symlink] Error 1
> make[4]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12487: recipe for target 'install-data-am' failed
> make[3]: *** [install-data-am] Error 2
> make[3]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12197: recipe for target 'install-am' failed
> make[2]: *** [install-am] Error 2
> make[2]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12191: recipe for target 'install' failed
> make[1]: *** [install] Error 2
> make[1]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:764: recipe for target 'install-recursive' failed
> make: *** [install-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-6851) make install fails the second time
[
https://issues.apache.org/jira/browse/MESOS-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808547#comment-16808547
]
Benjamin Bannier commented on MESOS-6851:
-
RPMs are provided by the Mesos community (currently only available on e.g.,
[https://builds.apache.org/view/M-R/view/Mesos/job/Packaging/job/CentOS/job/1.7.x/]
due to MESOS-9697). Mesosphere also provides Debian packages here,
[https://open.mesosphere.com/downloads/mesos/].
> make install fails the second time
> --
>
> Key: MESOS-6851
> URL: https://issues.apache.org/jira/browse/MESOS-6851
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: James Peach
>Priority: Major
>
> Run {{make install}} twice and the second time will fail when it tries to
> overwrite symlinks:
> {code}
> make[4]: Entering directory '/home/jpeach/upstream/mesos/build/src'
> cd //opt/mesos/etc/mesos && \
> ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
> ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
> Makefile:12952: recipe for target 'copy-template-and-create-symlink' failed
> make[4]: *** [copy-template-and-create-symlink] Error 1
> make[4]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12487: recipe for target 'install-data-am' failed
> make[3]: *** [install-data-am] Error 2
> make[3]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12197: recipe for target 'install-am' failed
> make[2]: *** [install-am] Error 2
> make[2]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12191: recipe for target 'install' failed
> make[1]: *** [install] Error 2
> make[1]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:764: recipe for target 'install-recursive' failed
> make: *** [install-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9697) Release RPMs are not uploaded to bintray
Benjamin Bannier created MESOS-9697: --- Summary: Release RPMs are not uploaded to bintray Key: MESOS-9697 URL: https://issues.apache.org/jira/browse/MESOS-9697 Project: Mesos Issue Type: Bug Components: build Affects Versions: 1.7.2, 1.6.2, 1.8.0 Reporter: Benjamin Bannier While we currently build release RPMs, e.g., [https://builds.apache.org/view/M-R/view/Mesos/job/Packaging/job/CentOS/job/1.7.x/], these artifacts are not uploaded to bintray. Due to that RPM links on the downloads page [http://mesos.apache.org/downloads/] are broken. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MESOS-6851) make install fails the second time
[
https://issues.apache.org/jira/browse/MESOS-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808527#comment-16808527
]
Jorge Machado edited comment on MESOS-6851 at 4/3/19 9:32 AM:
--
So I try it right now and it does not fit. It would much easier to provide deb
and rpms from the project...
My commands on Jenkins on a container ubuntu:1804:
{code:java}
sh("git clone https://github.com/mesosphere/mesos-deb-packaging.git | true ")
dir("mesos-deb-packaging"){
echo("Uninstalling existing installation")
sh("cd mesos-repo/build && make uninstall | true")
echo("The next step is going to take 5 min for cloning the repo")
sh("./build_mesos --repo https://github.com/apache/mesos?tag=${MESOS_VERSION}
--configure-flags '--enable-ssl --enable-libevent --disable-python
--disable-java'")
}{code}
Logs:
{code:java}
make install-exec-hook
make[4]: Entering directory
'/var/lib/jenkins/workspace/user/machjor/build_rpm_mesos_machjor@2/mesos-deb-packaging/mesos-repo/build/src'
cd
/var/lib/jenkins/workspace/user/machjor/build_rpm_mesos_machjor@2/mesos-deb-packaging/mesos-repo/toor//usr/etc/mesos
&& \
ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
Makefile:14819: recipe for target 'copy-template-and-create-symlink' failed
make[4]: *** [copy-template-and-create-symlink] Error 1
make[4]: Leaving directory
'/var/lib/jenkins/workspace/user//build_rpm_mesos_@2/mesos-deb-packaging/mesos-repo/build/src'
Makefile:14338: recipe for target 'install-data-am' failed
{code}
Any advice ?
was (Author: jomach):
So I try it right now and it does not fit. It would much easier to provide deb
and rpms from the project...
My commands on Jenkins on a container ubuntu:1804:
{code:java}
sh("git clone https://github.com/mesosphere/mesos-deb-packaging.git | true ")
dir("mesos-deb-packaging"){
echo("Uninstalling existing installation")
sh("cd mesos-repo/build && make uninstall | true")
echo("The next step is going to take 5 min for cloning the repo")
sh("./build_mesos --repo https://github.com/apache/mesos?tag=${MESOS_VERSION}
--configure-flags '--enable-ssl --enable-libevent --disable-python
--disable-java'")
}{code}
Logs:
{code:java}
make install-exec-hook
make[4]: Entering directory
'/var/lib/jenkins/workspace/user/machjor/build_rpm_mesos_machjor@2/mesos-deb-packaging/mesos-repo/build/src'
cd
/var/lib/jenkins/workspace/user/machjor/build_rpm_mesos_machjor@2/mesos-deb-packaging/mesos-repo/toor//usr/etc/mesos
&& \
ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
Makefile:14819: recipe for target 'copy-template-and-create-symlink' failed
make[4]: *** [copy-template-and-create-symlink] Error 1
make[4]: Leaving directory
'/var/lib/jenkins/workspace/user/machjor/build_rpm_mesos_machjor@2/mesos-deb-packaging/mesos-repo/build/src'
Makefile:14338: recipe for target 'install-data-am' failed
{code}
Any advice ?
> make install fails the second time
> --
>
> Key: MESOS-6851
> URL: https://issues.apache.org/jira/browse/MESOS-6851
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: James Peach
>Priority: Major
>
> Run {{make install}} twice and the second time will fail when it tries to
> overwrite symlinks:
> {code}
> make[4]: Entering directory '/home/jpeach/upstream/mesos/build/src'
> cd //opt/mesos/etc/mesos && \
> ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
> ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
> Makefile:12952: recipe for target 'copy-template-and-create-symlink' failed
> make[4]: *** [copy-template-and-create-symlink] Error 1
> make[4]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12487: recipe for target 'install-data-am' failed
> make[3]: *** [install-data-am] Error 2
> make[3]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12197: recipe for target 'install-am' failed
> make[2]: *** [install-am] Error 2
> make[2]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12191: recipe for target 'install' failed
> make[1]: *** [install] Error 2
> make[1]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:764: recipe for target 'install-recursive' failed
> make: *** [install-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-6851) make install fails the second time
[
https://issues.apache.org/jira/browse/MESOS-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808527#comment-16808527
]
Jorge Machado commented on MESOS-6851:
--
So I try it right now and it does not fit. It would much easier to provide deb
and rpms from the project...
My commands on Jenkins on a container ubuntu:1804:
{code:java}
sh("git clone https://github.com/mesosphere/mesos-deb-packaging.git | true ")
dir("mesos-deb-packaging"){
echo("Uninstalling existing installation")
sh("cd mesos-repo/build && make uninstall | true")
echo("The next step is going to take 5 min for cloning the repo")
sh("./build_mesos --repo https://github.com/apache/mesos?tag=${MESOS_VERSION}
--configure-flags '--enable-ssl --enable-libevent --disable-python
--disable-java'")
}{code}
Logs:
{code:java}
make install-exec-hook
make[4]: Entering directory
'/var/lib/jenkins/workspace/user/machjor/build_rpm_mesos_machjor@2/mesos-deb-packaging/mesos-repo/build/src'
cd
/var/lib/jenkins/workspace/user/machjor/build_rpm_mesos_machjor@2/mesos-deb-packaging/mesos-repo/toor//usr/etc/mesos
&& \
ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
Makefile:14819: recipe for target 'copy-template-and-create-symlink' failed
make[4]: *** [copy-template-and-create-symlink] Error 1
make[4]: Leaving directory
'/var/lib/jenkins/workspace/user/machjor/build_rpm_mesos_machjor@2/mesos-deb-packaging/mesos-repo/build/src'
Makefile:14338: recipe for target 'install-data-am' failed
{code}
Any advice ?
> make install fails the second time
> --
>
> Key: MESOS-6851
> URL: https://issues.apache.org/jira/browse/MESOS-6851
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: James Peach
>Priority: Major
>
> Run {{make install}} twice and the second time will fail when it tries to
> overwrite symlinks:
> {code}
> make[4]: Entering directory '/home/jpeach/upstream/mesos/build/src'
> cd //opt/mesos/etc/mesos && \
> ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
> ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
> Makefile:12952: recipe for target 'copy-template-and-create-symlink' failed
> make[4]: *** [copy-template-and-create-symlink] Error 1
> make[4]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12487: recipe for target 'install-data-am' failed
> make[3]: *** [install-data-am] Error 2
> make[3]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12197: recipe for target 'install-am' failed
> make[2]: *** [install-am] Error 2
> make[2]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12191: recipe for target 'install' failed
> make[1]: *** [install] Error 2
> make[1]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:764: recipe for target 'install-recursive' failed
> make: *** [install-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-6851) make install fails the second time
[
https://issues.apache.org/jira/browse/MESOS-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808481#comment-16808481
]
Benjamin Bannier commented on MESOS-6851:
-
[~jomach] , please uninstall the current installation before installing a new
version. What [~frankscholten] suggests just force-overwrites existing files,
but it e.g., does not guarantee that the previous installation hasn't left
incompatible artifacts behind.
Uninstalling is the correct solution.
> make install fails the second time
> --
>
> Key: MESOS-6851
> URL: https://issues.apache.org/jira/browse/MESOS-6851
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: James Peach
>Priority: Major
>
> Run {{make install}} twice and the second time will fail when it tries to
> overwrite symlinks:
> {code}
> make[4]: Entering directory '/home/jpeach/upstream/mesos/build/src'
> cd //opt/mesos/etc/mesos && \
> ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
> ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
> Makefile:12952: recipe for target 'copy-template-and-create-symlink' failed
> make[4]: *** [copy-template-and-create-symlink] Error 1
> make[4]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12487: recipe for target 'install-data-am' failed
> make[3]: *** [install-data-am] Error 2
> make[3]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12197: recipe for target 'install-am' failed
> make[2]: *** [install-am] Error 2
> make[2]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12191: recipe for target 'install' failed
> make[1]: *** [install] Error 2
> make[1]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:764: recipe for target 'install-recursive' failed
> make: *** [install-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MESOS-6851) make install fails the second time
[
https://issues.apache.org/jira/browse/MESOS-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808477#comment-16808477
]
Jorge Machado commented on MESOS-6851:
--
same problem here. I just checked for master and I cannot find the LN_S . Where
did you fixed it [~frankscholten] ? can you make a PR ?
> make install fails the second time
> --
>
> Key: MESOS-6851
> URL: https://issues.apache.org/jira/browse/MESOS-6851
> Project: Mesos
> Issue Type: Bug
> Components: build
>Reporter: James Peach
>Priority: Major
>
> Run {{make install}} twice and the second time will fail when it tries to
> overwrite symlinks:
> {code}
> make[4]: Entering directory '/home/jpeach/upstream/mesos/build/src'
> cd //opt/mesos/etc/mesos && \
> ln -s mesos-agent-env.sh.template mesos-slave-env.sh.template
> ln: failed to create symbolic link 'mesos-slave-env.sh.template': File exists
> Makefile:12952: recipe for target 'copy-template-and-create-symlink' failed
> make[4]: *** [copy-template-and-create-symlink] Error 1
> make[4]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12487: recipe for target 'install-data-am' failed
> make[3]: *** [install-data-am] Error 2
> make[3]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12197: recipe for target 'install-am' failed
> make[2]: *** [install-am] Error 2
> make[2]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:12191: recipe for target 'install' failed
> make[1]: *** [install] Error 2
> make[1]: Leaving directory '/home/jpeach/upstream/mesos/build/src'
> Makefile:764: recipe for target 'install-recursive' failed
> make: *** [install-recursive] Error 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MESOS-9696) Test MasterQuotaTest.AvailableResourcesSingleDisconnectedAgent is flaky
Benjamin Bannier created MESOS-9696:
---
Summary: Test
MasterQuotaTest.AvailableResourcesSingleDisconnectedAgent is flaky
Key: MESOS-9696
URL: https://issues.apache.org/jira/browse/MESOS-9696
Project: Mesos
Issue Type: Bug
Components: test
Affects Versions: 1.8.0
Reporter: Benjamin Bannier
Attachments: test.log
The test {{MasterQuotaTest.AvailableResourcesSingleDisconnectedAgent}} is
flaky, especially under additional system load.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
