FAQ
Hello, i have a question about using orchestrate runner with multiple
environments.

I have multiple environments and used to work with highstate on them, using
declarative description in top.sls in states and in top.sls in pillar.
Them i tried to move to orchestration system as my states on minions begin
to depend on each other.
When i made an orchestrate sls file and wrote highstates only there and
added some requirements in order to describe my top.sls cross minions
dependencies, i ran into a big problem using orchestrate runner: execution
like salt-run state.orch orchestration.mycluster *uses only base
environment*.
U can see in develop branch code like this:
def orchestrate(mods, saltenv='base', test=None, exclude=None, pillar=None):
It was a disappointment for me. I really don't understand why do u have to
restrict explicit env specification when running orchestrate, while when
using state.highstate environments and appropriate matches for them could
be declarative described in top.sls.

Is it a bug or my misunderstanding? Please, help.

Also in new rc there is an orchestrate_highstate runner, can u tell, what
is it for? I tried using it, but it failed with exception.

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Anton at Apr 15, 2015 at 9:51 am
    Someone, please answer.
    On Tuesday, April 14, 2015 at 11:57:37 AM UTC+3, Anton wrote:

    Hello, i have a question about using orchestrate runner with multiple
    environments.

    I have multiple environments and used to work with highstate on them,
    using declarative description in top.sls in states and in top.sls in pillar.
    Them i tried to move to orchestration system as my states on minions begin
    to depend on each other.
    When i made an orchestrate sls file and wrote highstates only there and
    added some requirements in order to describe my top.sls cross minions
    dependencies, i ran into a big problem using orchestrate runner: execution
    like salt-run state.orch orchestration.mycluster *uses only base
    environment*.
    U can see in develop branch code like this:
    def orchestrate(mods, saltenv='base', test=None, exclude=None, pillar=None
    ):
    It was a disappointment for me. I really don't understand why do u have to
    restrict explicit env specification when running orchestrate, while when
    using state.highstate environments and appropriate matches for them could
    be declarative described in top.sls.

    Is it a bug or my misunderstanding? Please, help.

    Also in new rc there is an orchestrate_highstate runner, can u tell, what
    is it for? I tried using it, but it failed with exception.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Anton at Apr 20, 2015 at 9:39 am
    ?
    On Tuesday, April 14, 2015 at 11:57:37 AM UTC+3, Anton wrote:

    Hello, i have a question about using orchestrate runner with multiple
    environments.

    I have multiple environments and used to work with highstate on them,
    using declarative description in top.sls in states and in top.sls in pillar.
    Them i tried to move to orchestration system as my states on minions begin
    to depend on each other.
    When i made an orchestrate sls file and wrote highstates only there and
    added some requirements in order to describe my top.sls cross minions
    dependencies, i ran into a big problem using orchestrate runner: execution
    like salt-run state.orch orchestration.mycluster *uses only base
    environment*.
    U can see in develop branch code like this:
    def orchestrate(mods, saltenv='base', test=None, exclude=None, pillar=None
    ):
    It was a disappointment for me. I really don't understand why do u have to
    restrict explicit env specification when running orchestrate, while when
    using state.highstate environments and appropriate matches for them could
    be declarative described in top.sls.

    Is it a bug or my misunderstanding? Please, help.

    Also in new rc there is an orchestrate_highstate runner, can u tell, what
    is it for? I tried using it, but it failed with exception.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Colton Myers at Apr 22, 2015 at 10:22 pm
    Have you actually observed the orchestrate runner only using the `base`
    environment? Just because that's the default argument doesn't mean it's
    necessarily enforcing it to the state.highstate calls it makes to the
    minions. If it's enforcing it all the way down, we should definitely get
    this fixed, there's not reason to restrict orchestrate to a single
    environment. You should file an issue if this is the case.

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Twitter/Github/IRC
    On Mon, Apr 20, 2015 at 3:39 AM, Anton wrote:

    ?
    On Tuesday, April 14, 2015 at 11:57:37 AM UTC+3, Anton wrote:

    Hello, i have a question about using orchestrate runner with multiple
    environments.

    I have multiple environments and used to work with highstate on them,
    using declarative description in top.sls in states and in top.sls in pillar.
    Them i tried to move to orchestration system as my states on minions
    begin to depend on each other.
    When i made an orchestrate sls file and wrote highstates only there and
    added some requirements in order to describe my top.sls cross minions
    dependencies, i ran into a big problem using orchestrate runner: execution
    like salt-run state.orch orchestration.mycluster *uses only base
    environment*.
    U can see in develop branch code like this:
    def orchestrate(mods, saltenv='base', test=None, exclude=None, pillar=
    None):
    It was a disappointment for me. I really don't understand why do u have
    to restrict explicit env specification when running orchestrate, while when
    using state.highstate environments and appropriate matches for them could
    be declarative described in top.sls.

    Is it a bug or my misunderstanding? Please, help.

    Also in new rc there is an orchestrate_highstate runner, can u tell, what
    is it for? I tried using it, but it failed with exception.
    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Anton at Apr 23, 2015 at 8:30 am
    Yes, it's actually enforcing and i think it can be considered as bug as it
    ruins the concept of declarative environments description in highstates.
    On Thursday, April 23, 2015 at 1:22:26 AM UTC+3, basepi wrote:

    Have you actually observed the orchestrate runner only using the `base`
    environment? Just because that's the default argument doesn't mean it's
    necessarily enforcing it to the state.highstate calls it makes to the
    minions. If it's enforcing it all the way down, we should definitely get
    this fixed, there's not reason to restrict orchestrate to a single
    environment. You should file an issue if this is the case.

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Twitter/Github/IRC

    On Mon, Apr 20, 2015 at 3:39 AM, Anton <ton.m...@gmail.com <javascript:>>
    wrote:
    ?
    On Tuesday, April 14, 2015 at 11:57:37 AM UTC+3, Anton wrote:

    Hello, i have a question about using orchestrate runner with multiple
    environments.

    I have multiple environments and used to work with highstate on them,
    using declarative description in top.sls in states and in top.sls in pillar.
    Them i tried to move to orchestration system as my states on minions
    begin to depend on each other.
    When i made an orchestrate sls file and wrote highstates only there and
    added some requirements in order to describe my top.sls cross minions
    dependencies, i ran into a big problem using orchestrate runner: execution
    like salt-run state.orch orchestration.mycluster *uses only base
    environment*.
    U can see in develop branch code like this:
    def orchestrate(mods, saltenv='base', test=None, exclude=None, pillar=
    None):
    It was a disappointment for me. I really don't understand why do u have
    to restrict explicit env specification when running orchestrate, while when
    using state.highstate environments and appropriate matches for them could
    be declarative described in top.sls.

    Is it a bug or my misunderstanding? Please, help.

    Also in new rc there is an orchestrate_highstate runner, can u tell,
    what is it for? I tried using it, but it failed with exception.
    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Anton at Apr 23, 2015 at 8:34 am
    Can u also give me a clue about what new orchestrate_high runner that is in
    develop branch is for?
    On Thursday, April 23, 2015 at 11:30:43 AM UTC+3, Anton wrote:

    Yes, it's actually enforcing and i think it can be considered as bug as it
    ruins the concept of declarative environments description in highstates.
    On Thursday, April 23, 2015 at 1:22:26 AM UTC+3, basepi wrote:

    Have you actually observed the orchestrate runner only using the `base`
    environment? Just because that's the default argument doesn't mean it's
    necessarily enforcing it to the state.highstate calls it makes to the
    minions. If it's enforcing it all the way down, we should definitely get
    this fixed, there's not reason to restrict orchestrate to a single
    environment. You should file an issue if this is the case.

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Twitter/Github/IRC
    On Mon, Apr 20, 2015 at 3:39 AM, Anton wrote:

    ?
    On Tuesday, April 14, 2015 at 11:57:37 AM UTC+3, Anton wrote:

    Hello, i have a question about using orchestrate runner with multiple
    environments.

    I have multiple environments and used to work with highstate on them,
    using declarative description in top.sls in states and in top.sls in pillar.
    Them i tried to move to orchestration system as my states on minions
    begin to depend on each other.
    When i made an orchestrate sls file and wrote highstates only there and
    added some requirements in order to describe my top.sls cross minions
    dependencies, i ran into a big problem using orchestrate runner: execution
    like salt-run state.orch orchestration.mycluster *uses only base
    environment*.
    U can see in develop branch code like this:
    def orchestrate(mods, saltenv='base', test=None, exclude=None, pillar=
    None):
    It was a disappointment for me. I really don't understand why do u have
    to restrict explicit env specification when running orchestrate, while when
    using state.highstate environments and appropriate matches for them could
    be declarative described in top.sls.

    Is it a bug or my misunderstanding? Please, help.

    Also in new rc there is an orchestrate_highstate runner, can u tell,
    what is it for? I tried using it, but it failed with exception.
    --
    You received this message because you are subscribed to the Google
    Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to salt-users+...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Colton Myers at Apr 28, 2015 at 5:06 pm
    Could you file an issue on Github? We should definitely investigate this.

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Twitter/Github/IRC
    On Thu, Apr 23, 2015 at 2:30 AM, Anton wrote:

    Yes, it's actually enforcing and i think it can be considered as bug as it
    ruins the concept of declarative environments description in highstates.
    On Thursday, April 23, 2015 at 1:22:26 AM UTC+3, basepi wrote:

    Have you actually observed the orchestrate runner only using the `base`
    environment? Just because that's the default argument doesn't mean it's
    necessarily enforcing it to the state.highstate calls it makes to the
    minions. If it's enforcing it all the way down, we should definitely get
    this fixed, there's not reason to restrict orchestrate to a single
    environment. You should file an issue if this is the case.

    --
    Colton Myers
    Platform Engineer, SaltStack
    @basepi on Twitter/Github/IRC
    On Mon, Apr 20, 2015 at 3:39 AM, Anton wrote:

    ?
    On Tuesday, April 14, 2015 at 11:57:37 AM UTC+3, Anton wrote:

    Hello, i have a question about using orchestrate runner with multiple
    environments.

    I have multiple environments and used to work with highstate on them,
    using declarative description in top.sls in states and in top.sls in pillar.
    Them i tried to move to orchestration system as my states on minions
    begin to depend on each other.
    When i made an orchestrate sls file and wrote highstates only there and
    added some requirements in order to describe my top.sls cross minions
    dependencies, i ran into a big problem using orchestrate runner: execution
    like salt-run state.orch orchestration.mycluster *uses only base
    environment*.
    U can see in develop branch code like this:
    def orchestrate(mods, saltenv='base', test=None, exclude=None, pillar=
    None):
    It was a disappointment for me. I really don't understand why do u have
    to restrict explicit env specification when running orchestrate, while when
    using state.highstate environments and appropriate matches for them could
    be declarative described in top.sls.

    Is it a bug or my misunderstanding? Please, help.

    Also in new rc there is an orchestrate_highstate runner, can u tell,
    what is it for? I tried using it, but it failed with exception.
    --
    You received this message because you are subscribed to the Google
    Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to salt-users+...@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups
    "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedApr 14, '15 at 8:57a
activeApr 28, '15 at 5:06p
posts7
users2

2 users in discussion

Anton: 5 posts Colton Myers: 2 posts

People

Translate

site design / logo © 2021 Grokbase