[
https://issues.apache.org/jira/browse/MESOS-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Harper updated MESOS-8148:
------------------------------
Description:
Mesos has a specification for characters allowed by attribute values:
http://mesos.apache.org/documentation/latest/attributes-resources/
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.
was:
Mesos has a specification for characters allowed by attribute values:
http://mesos.apache.org/documentation/latest/attributes-resources/
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 uses the Mesos set value
type specification to describe a set of zones in which an app would be
deployed, and, 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.
> 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
>
> Mesos has a specification for characters allowed by attribute values:
> http://mesos.apache.org/documentation/latest/attributes-resources/
> 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
(v6.4.14#64029)
