client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
package consul
|
|
|
|
|
|
|
|
import (
|
2020-02-14 19:44:34 +00:00
|
|
|
"reflect"
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
"testing"
|
|
|
|
|
|
|
|
"github.com/hashicorp/consul/api"
|
|
|
|
"github.com/stretchr/testify/require"
|
|
|
|
)
|
|
|
|
|
2020-02-14 19:44:34 +00:00
|
|
|
var (
|
|
|
|
// the service as known by nomad
|
|
|
|
wanted = api.AgentServiceRegistration{
|
|
|
|
Kind: "",
|
|
|
|
ID: "aca4c175-1778-5ef4-0220-2ab434147d35",
|
|
|
|
Name: "myservice",
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
Tags: []string{"a", "b"},
|
|
|
|
Port: 9000,
|
|
|
|
Address: "1.1.1.1",
|
|
|
|
EnableTagOverride: true,
|
|
|
|
Meta: map[string]string{"foo": "1"},
|
2020-02-14 19:44:34 +00:00
|
|
|
Connect: &api.AgentServiceConnect{
|
|
|
|
Native: false,
|
|
|
|
SidecarService: &api.AgentServiceRegistration{
|
|
|
|
Kind: "connect-proxy",
|
|
|
|
ID: "_nomad-task-8e8413af-b5bb-aa67-2c24-c146c45f1ec9-group-mygroup-myservice-9001-sidecar-proxy",
|
|
|
|
Name: "name-sidecar-proxy",
|
|
|
|
Tags: []string{"x", "y", "z"},
|
|
|
|
},
|
|
|
|
},
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
}
|
|
|
|
|
2020-02-14 19:44:34 +00:00
|
|
|
// the service (and + connect proxy) as known by consul
|
|
|
|
existing = &api.AgentService{
|
|
|
|
Kind: "",
|
|
|
|
ID: "aca4c175-1778-5ef4-0220-2ab434147d35",
|
|
|
|
Service: "myservice",
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
Tags: []string{"a", "b"},
|
|
|
|
Port: 9000,
|
|
|
|
Address: "1.1.1.1",
|
|
|
|
EnableTagOverride: true,
|
|
|
|
Meta: map[string]string{"foo": "1"},
|
|
|
|
}
|
|
|
|
|
2020-02-14 19:44:34 +00:00
|
|
|
sidecar = &api.AgentService{
|
|
|
|
Kind: "connect-proxy",
|
|
|
|
ID: "_nomad-task-8e8413af-b5bb-aa67-2c24-c146c45f1ec9-group-mygroup-myservice-9001-sidecar-proxy",
|
|
|
|
Service: "myservice-sidecar-proxy",
|
|
|
|
Tags: []string{"x", "y", "z"},
|
|
|
|
}
|
|
|
|
)
|
|
|
|
|
|
|
|
func TestSyncLogic_agentServiceUpdateRequired(t *testing.T) {
|
|
|
|
t.Parallel()
|
|
|
|
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
// By default wanted and existing match. Each test should modify wanted in
|
|
|
|
// 1 way, and / or configure the type of sync operation that is being
|
|
|
|
// considered, then evaluate the result of the update-required algebra.
|
|
|
|
|
|
|
|
type asr = api.AgentServiceRegistration
|
|
|
|
type tweaker func(w asr) *asr // create a conveniently modifiable copy
|
|
|
|
|
|
|
|
try := func(
|
|
|
|
t *testing.T,
|
|
|
|
exp bool,
|
|
|
|
reason syncReason,
|
|
|
|
tweak tweaker) {
|
2020-02-14 19:44:34 +00:00
|
|
|
result := agentServiceUpdateRequired(reason, tweak(wanted), existing, sidecar)
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
require.Equal(t, exp, result)
|
|
|
|
}
|
|
|
|
|
|
|
|
t.Run("matching", func(t *testing.T) {
|
|
|
|
try(t, false, syncNewOps, func(w asr) *asr {
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("different kind", func(t *testing.T) {
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.Kind = "other"
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("different id", func(t *testing.T) {
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.ID = "_other"
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("different port", func(t *testing.T) {
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.Port = 9001
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("different address", func(t *testing.T) {
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.Address = "2.2.2.2"
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("different name", func(t *testing.T) {
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.Name = "bob"
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("different enable_tag_override", func(t *testing.T) {
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.EnableTagOverride = false
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("different meta", func(t *testing.T) {
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.Meta = map[string]string{"foo": "2"}
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2020-02-14 19:44:34 +00:00
|
|
|
t.Run("different tags syncNewOps eto=true", func(t *testing.T) {
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
// sync is required even though eto=true, because NewOps indicates the
|
|
|
|
// service definition in nomad has changed (e.g. job run a modified job)
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.Tags = []string{"other", "tags"}
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2020-02-14 19:44:34 +00:00
|
|
|
t.Run("different tags syncPeriodic eto=true", func(t *testing.T) {
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
// sync is not required since eto=true and this is a periodic sync
|
|
|
|
// with consul - in which case we keep Consul's definition of the tags
|
|
|
|
try(t, false, syncPeriodic, func(w asr) *asr {
|
|
|
|
w.Tags = []string{"other", "tags"}
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2020-02-14 19:44:34 +00:00
|
|
|
t.Run("different sidecar tags on syncPeriodic eto=true", func(t *testing.T) {
|
|
|
|
try(t, false, syncPeriodic, func(w asr) *asr {
|
|
|
|
// like the parent service, the sidecar's tags do not get enforced
|
|
|
|
// if ETO is true and this is a periodic sync
|
|
|
|
w.Connect.SidecarService.Tags = []string{"other", "tags"}
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("different sidecar tags on syncNewOps eto=true", func(t *testing.T) {
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
// like the parent service, the sidecar's tags always get enforced
|
|
|
|
// regardless of ETO if this is a sync due to applied operations
|
|
|
|
w.Connect.SidecarService.Tags = []string{"other", "tags"}
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
// for remaining tests, EnableTagOverride = false
|
|
|
|
wanted.EnableTagOverride = false
|
|
|
|
existing.EnableTagOverride = false
|
|
|
|
|
2020-02-14 19:44:34 +00:00
|
|
|
t.Run("different tags syncPeriodic eto=false", func(t *testing.T) {
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
// sync is required because eto=false and the tags do not match
|
|
|
|
try(t, true, syncPeriodic, func(w asr) *asr {
|
|
|
|
w.Tags = []string{"other", "tags"}
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2020-02-14 19:44:34 +00:00
|
|
|
t.Run("different tags syncNewOps eto=false", func(t *testing.T) {
|
|
|
|
// sync is required because eto=false and the tags do not match
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.Tags = []string{"other", "tags"}
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
2020-02-14 19:44:34 +00:00
|
|
|
|
|
|
|
t.Run("different sidecar tags on syncPeriodic eto=false", func(t *testing.T) {
|
|
|
|
// like the parent service, sync is required because eto=false and the
|
|
|
|
// sidecar's tags do not match
|
|
|
|
try(t, true, syncPeriodic, func(w asr) *asr {
|
|
|
|
w.Connect.SidecarService.Tags = []string{"other", "tags"}
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
t.Run("different sidecar tags syncNewOps eto=false", func(t *testing.T) {
|
|
|
|
// like the parent service, sync is required because eto=false and the
|
|
|
|
// sidecar's tags do not match
|
|
|
|
try(t, true, syncNewOps, func(w asr) *asr {
|
|
|
|
w.Connect.SidecarService.Tags = []string{"other", "tags"}
|
|
|
|
return &w
|
|
|
|
})
|
|
|
|
})
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func TestSyncLogic_maybeTweakTags(t *testing.T) {
|
|
|
|
t.Parallel()
|
2020-02-14 19:44:34 +00:00
|
|
|
|
|
|
|
differentPointers := func(a, b []string) bool {
|
|
|
|
return &(a) != &(b)
|
|
|
|
}
|
|
|
|
|
|
|
|
try := func(inConsul, inConsulSC []string, eto bool) {
|
|
|
|
wanted := &api.AgentServiceRegistration{
|
|
|
|
Tags: []string{"original"},
|
|
|
|
Connect: &api.AgentServiceConnect{
|
|
|
|
SidecarService: &api.AgentServiceRegistration{
|
|
|
|
Tags: []string{"original-sidecar"},
|
|
|
|
},
|
|
|
|
},
|
|
|
|
EnableTagOverride: eto,
|
|
|
|
}
|
|
|
|
|
|
|
|
existing := &api.AgentService{Tags: inConsul}
|
|
|
|
sidecar := &api.AgentService{Tags: inConsulSC}
|
|
|
|
|
|
|
|
maybeTweakTags(wanted, existing, sidecar)
|
|
|
|
|
|
|
|
switch eto {
|
|
|
|
case false:
|
|
|
|
require.Equal(t, []string{"original"}, wanted.Tags)
|
|
|
|
require.Equal(t, []string{"original-sidecar"}, wanted.Connect.SidecarService.Tags)
|
|
|
|
require.True(t, differentPointers(wanted.Tags, wanted.Connect.SidecarService.Tags))
|
|
|
|
case true:
|
|
|
|
require.Equal(t, inConsul, wanted.Tags)
|
|
|
|
require.Equal(t, inConsulSC, wanted.Connect.SidecarService.Tags)
|
|
|
|
require.True(t, differentPointers(wanted.Tags, wanted.Connect.SidecarService.Tags))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
try([]string{"original"}, []string{"original-sidecar"}, true)
|
|
|
|
try([]string{"original"}, []string{"original-sidecar"}, false)
|
|
|
|
try([]string{"modified"}, []string{"original-sidecar"}, true)
|
|
|
|
try([]string{"modified"}, []string{"original-sidecar"}, false)
|
|
|
|
try([]string{"original"}, []string{"modified-sidecar"}, true)
|
|
|
|
try([]string{"original"}, []string{"modified-sidecar"}, false)
|
|
|
|
try([]string{"modified"}, []string{"modified-sidecar"}, true)
|
|
|
|
try([]string{"modified"}, []string{"modified-sidecar"}, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestSyncLogic_maybeTweakTags_emptySC(t *testing.T) {
|
|
|
|
t.Parallel()
|
|
|
|
|
|
|
|
// Check the edge cases where the connect service is deleted on the nomad
|
|
|
|
// side (i.e. are we checking multiple nil pointers).
|
|
|
|
|
|
|
|
try := func(asr *api.AgentServiceRegistration) {
|
|
|
|
maybeTweakTags(asr, existing, sidecar)
|
|
|
|
require.False(t, reflect.DeepEqual([]string{"original"}, asr.Tags))
|
|
|
|
}
|
|
|
|
|
|
|
|
try(&api.AgentServiceRegistration{
|
|
|
|
Tags: []string{"original"},
|
|
|
|
EnableTagOverride: true,
|
|
|
|
Connect: nil, // ooh danger!
|
|
|
|
})
|
|
|
|
|
|
|
|
try(&api.AgentServiceRegistration{
|
|
|
|
Tags: []string{"original"},
|
|
|
|
EnableTagOverride: true,
|
|
|
|
Connect: &api.AgentServiceConnect{
|
|
|
|
SidecarService: nil, // ooh danger!
|
|
|
|
},
|
|
|
|
})
|
client: enable configuring enable_tag_override for services
Consul provides a feature of Service Definitions where the tags
associated with a service can be modified through the Catalog API,
overriding the value(s) configured in the agent's service configuration.
To enable this feature, the flag enable_tag_override must be configured
in the service definition.
Previously, Nomad did not allow configuring this flag, and thus the default
value of false was used. Now, it is configurable.
Because Nomad itself acts as a state machine around the the service definitions
of the tasks it manages, it's worth describing what happens when this feature
is enabled and why.
Consider the basic case where there is no Nomad, and your service is provided
to consul as a boring JSON file. The ultimate source of truth for the definition
of that service is the file, and is stored in the agent. Later, Consul performs
"anti-entropy" which synchronizes the Catalog (stored only the leaders). Then
with enable_tag_override=true, the tags field is available for "external"
modification through the Catalog API (rather than directly configuring the
service definition file, or using the Agent API). The important observation
is that if the service definition ever changes (i.e. the file is changed &
config reloaded OR the Agent API is used to modify the service), those
"external" tag values are thrown away, and the new service definition is
once again the source of truth.
In the Nomad case, Nomad itself is the source of truth over the Agent in
the same way the JSON file was the source of truth in the example above.
That means any time Nomad sets a new service definition, any externally
configured tags are going to be replaced. When does this happen? Only on
major lifecycle events, for example when a task is modified because of an
updated job spec from the 'nomad job run <existing>' command. Otherwise,
Nomad's periodic re-sync's with Consul will now no longer try to restore
the externally modified tag values (as long as enable_tag_override=true).
Fixes #2057
2020-02-07 21:22:19 +00:00
|
|
|
}
|