New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

States that include other states is causing "conflicting IDs" errors. #7526

Closed
luizsilva opened this Issue Sep 30, 2013 · 31 comments

Comments

Projects
None yet
@luizsilva

luizsilva commented Sep 30, 2013

Using salt 0.17
On my top.sls I have

base:
  '*'
    - github
    - openssh

The github state include openssh state. That is generating this error message:

Data failed to compile:
----------
    Detected conflicting IDs, SLS IDs need to be globally unique.

If I remove the includes, the highstate runs normaly.

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Oct 1, 2013

Collaborator

Right, the include pulls those states in. So if you include the openssh state in the github state you should not put the openssh state in your top.sls.

Collaborator

basepi commented Oct 1, 2013

Right, the include pulls those states in. So if you include the openssh state in the github state you should not put the openssh state in your top.sls.

@luizsilva

This comment has been minimized.

Show comment
Hide comment
@luizsilva

luizsilva Oct 1, 2013

The weird thing is that it was working fine on 0.16.

It was very useful when running a single state that depended on other states.

luizsilva commented Oct 1, 2013

The weird thing is that it was working fine on 0.16.

It was very useful when running a single state that depended on other states.

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Oct 1, 2013

Collaborator

Ah, didn't realize this was a regression. Thanks for pointing that out, we'll get this fixed.

Collaborator

basepi commented Oct 1, 2013

Ah, didn't realize this was a regression. Thanks for pointing that out, we'll get this fixed.

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Oct 7, 2013

Collaborator

@luizsilva Are you using 0.17.0, or a more recent build from git? Just want to make sure, as there was a change to includes (to fix wildcards) but it was after 0.17.0 was released.

Collaborator

basepi commented Oct 7, 2013

@luizsilva Are you using 0.17.0, or a more recent build from git? Just want to make sure, as there was a change to includes (to fix wildcards) but it was after 0.17.0 was released.

@luizsilva

This comment has been minimized.

Show comment
Hide comment
@luizsilva

luizsilva Oct 7, 2013

@basepi We are using salt 0.17.0 (yaourt package version 0.17.0-1 on Arch linux)

I will wait for the package maintainer to update it and I will test again.

luizsilva commented Oct 7, 2013

@basepi We are using salt 0.17.0 (yaourt package version 0.17.0-1 on Arch linux)

I will wait for the package maintainer to update it and I will test again.

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Oct 9, 2013

Collaborator

OK, then this regression was not caused by the fix I mentioned. We'll figure out what's going on here and get it fixed.

Collaborator

basepi commented Oct 9, 2013

OK, then this regression was not caused by the fix I mentioned. We'll figure out what's going on here and get it fixed.

@hobbestigrou

This comment has been minimized.

Show comment
Hide comment
@hobbestigrou

hobbestigrou Oct 9, 2013

We have the same problem. We hope it's be resolved soon.

hobbestigrou commented Oct 9, 2013

We have the same problem. We hope it's be resolved soon.

@Lothiraldan

This comment has been minimized.

Show comment
Hide comment
@Lothiraldan

Lothiraldan Oct 9, 2013

Contributor

I think the include system mimic the import in python. If states has already been included (either in top.sls or by other state), do not try to include it one more time.

Contributor

Lothiraldan commented Oct 9, 2013

I think the include system mimic the import in python. If states has already been included (either in top.sls or by other state), do not try to include it one more time.

@max-arnold

This comment has been minimized.

Show comment
Hide comment
@max-arnold

max-arnold Oct 9, 2013

Contributor

Same problem here, lots of duplicate IDs on 0.17.0

Contributor

max-arnold commented Oct 9, 2013

Same problem here, lots of duplicate IDs on 0.17.0

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Oct 9, 2013

Collaborator

Thanks for the additional reports. This is high on our priority list.

Collaborator

basepi commented Oct 9, 2013

Thanks for the additional reports. This is high on our priority list.

@JustinCarmony

This comment has been minimized.

Show comment
Hide comment
@JustinCarmony

JustinCarmony Oct 14, 2013

Contributor

Ok, so I've had this problem as well on develop and v0.17.0.

What seems to be the problem is if you include a state file via the top.sls, you cannot include it in any other state files.

so if I have a common/init.sls state file, I can't currently do a:

base:
  '*':
    - common

and then later in something like a php5/init.sls file:

include:
  - common

However, php5/init.sls and nginx/init.sls both can include common as long as it isn't included in the top.sls file.

I hope this helps track down the bug.

Contributor

JustinCarmony commented Oct 14, 2013

Ok, so I've had this problem as well on develop and v0.17.0.

What seems to be the problem is if you include a state file via the top.sls, you cannot include it in any other state files.

so if I have a common/init.sls state file, I can't currently do a:

base:
  '*':
    - common

and then later in something like a php5/init.sls file:

include:
  - common

However, php5/init.sls and nginx/init.sls both can include common as long as it isn't included in the top.sls file.

I hope this helps track down the bug.

@tateeskew

This comment has been minimized.

Show comment
Hide comment
@tateeskew

tateeskew Oct 14, 2013

Add me to this list. Same exact behavior.

tateeskew commented Oct 14, 2013

Add me to this list. Same exact behavior.

@HuangShaoyan

This comment has been minimized.

Show comment
Hide comment
@HuangShaoyan

HuangShaoyan Oct 15, 2013

I use overstate as a workaround. It looks good. But please fix it as soon as possible.

HuangShaoyan commented Oct 15, 2013

I use overstate as a workaround. It looks good. But please fix it as soon as possible.

@thatch45 thatch45 closed this in 73d1b6a Oct 15, 2013

thatch45 added a commit that referenced this issue Oct 15, 2013

Fix #7526
This should prevent already loaded mods from being reloaded from the
top level of the matches

thatch45 added a commit that referenced this issue Oct 16, 2013

thatch45 added a commit that referenced this issue Oct 16, 2013

@sblask

This comment has been minimized.

Show comment
Hide comment
@sblask

sblask Nov 20, 2013

We still have an issue with this using 0.17.2. Did you actually have another fix after reverting the fix in da8a60f/2f71e6f ?

sblask commented Nov 20, 2013

We still have an issue with this using 0.17.2. Did you actually have another fix after reverting the fix in da8a60f/2f71e6f ?

@tateeskew

This comment has been minimized.

Show comment
Hide comment
@tateeskew

tateeskew Nov 20, 2013

I can confirm that this is still the case as well.

tateeskew commented Nov 20, 2013

I can confirm that this is still the case as well.

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Nov 20, 2013

Collaborator

What's the issue you're seeing? The same "conflicting IDs on imported states" problems?

Collaborator

basepi commented Nov 20, 2013

What's the issue you're seeing? The same "conflicting IDs on imported states" problems?

@sblask

This comment has been minimized.

Show comment
Hide comment
@sblask

sblask Nov 21, 2013

Yes, same thing.

sblask commented Nov 21, 2013

Yes, same thing.

@basepi basepi reopened this Nov 21, 2013

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Nov 21, 2013

Collaborator

Alright, re-opened. Guess we still need to try to fix this without breaking PyDSL.

Collaborator

basepi commented Nov 21, 2013

Alright, re-opened. Guess we still need to try to fix this without breaking PyDSL.

@sblask

This comment has been minimized.

Show comment
Hide comment
@sblask

sblask Nov 22, 2013

Because of this problem and the slowness, we tried not using gitfs anymore. Now we work from manual checkouts and replaced the different environments we had with standard git branching. Without actually changing the states, the problem doesn't occur anymore. So it's probably related to using different environments?

sblask commented Nov 22, 2013

Because of this problem and the slowness, we tried not using gitfs anymore. Now we work from manual checkouts and replaced the different environments we had with standard git branching. Without actually changing the states, the problem doesn't occur anymore. So it's probably related to using different environments?

@tateeskew

This comment has been minimized.

Show comment
Hide comment
@tateeskew

tateeskew Nov 22, 2013

My use case is identical to the original problem and it still exists in .17.2
This is kind of a big deal because it basically renders the include statement obsolete in a lot of cases. Especially when you have states within non-base states that have a require statement from something that was to be included.

tateeskew commented Nov 22, 2013

My use case is identical to the original problem and it still exists in .17.2
This is kind of a big deal because it basically renders the include statement obsolete in a lot of cases. Especially when you have states within non-base states that have a require statement from something that was to be included.

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Nov 25, 2013

Collaborator

Can you guys post some example SLS files that consistently cause this error? We need to try to reproduce it again on our end.

Collaborator

basepi commented Nov 25, 2013

Can you guys post some example SLS files that consistently cause this error? We need to try to reproduce it again on our end.

@tateeskew

This comment has been minimized.

Show comment
Hide comment
@tateeskew

tateeskew commented Nov 25, 2013

@jeteokeeffe

This comment has been minimized.

Show comment
Hide comment
@jeteokeeffe

jeteokeeffe Nov 29, 2013

Contributor

Another example if you needed one
https://gist.github.com/jeteokeeffe/7700914

Contributor

jeteokeeffe commented Nov 29, 2013

Another example if you needed one
https://gist.github.com/jeteokeeffe/7700914

@medcl

This comment has been minimized.

Show comment
Hide comment
@medcl

medcl Dec 26, 2013

global unique is not ideal,maybe auto adding folder name as part of sls-id,that will be more nice to use.

medcl commented Dec 26, 2013

global unique is not ideal,maybe auto adding folder name as part of sls-id,that will be more nice to use.

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Dec 26, 2013

Collaborator

@medcl No worries, this is definitely a bug which we're working to fix.

Collaborator

basepi commented Dec 26, 2013

@medcl No worries, this is definitely a bug which we're working to fix.

@medcl

This comment has been minimized.

Show comment
Hide comment
@medcl

medcl Dec 27, 2013

great!

-------- 原始邮件 --------
发件人:Colton Myers notifications@github.com
时间:周五 12月27日 03:16
收件人:saltstack/salt salt@noreply.github.com
抄送:Medcl m@medcl.net
主题:Re: [salt] States that include other states is causing "conflicting IDs" errors. (#7526)

@medcl No worries, this is definitely a bug which we're working to fix.


Reply to this email directly or view it on GitHub:
#7526 (comment)

medcl commented Dec 27, 2013

great!

-------- 原始邮件 --------
发件人:Colton Myers notifications@github.com
时间:周五 12月27日 03:16
收件人:saltstack/salt salt@noreply.github.com
抄送:Medcl m@medcl.net
主题:Re: [salt] States that include other states is causing "conflicting IDs" errors. (#7526)

@medcl No worries, this is definitely a bug which we're working to fix.


Reply to this email directly or view it on GitHub:
#7526 (comment)

@basepi

This comment has been minimized.

Show comment
Hide comment
@basepi

basepi Dec 27, 2013

Collaborator

So I have had some long-standing misunderstandings with the way this is supposed to work.

State IDs must be globally unique across a single state run. This won't be changing. I was under the impression that you could have the same state ID in two different state files in the same highstate as long as they didn't include each other. This is false.

That said, if you define an ID in a state file defined in the top.sls, and then also include that state file in a different state file defined in top.sls, this should not be producing conflicting ID errors.

(Edited for clarifications)

Collaborator

basepi commented Dec 27, 2013

So I have had some long-standing misunderstandings with the way this is supposed to work.

State IDs must be globally unique across a single state run. This won't be changing. I was under the impression that you could have the same state ID in two different state files in the same highstate as long as they didn't include each other. This is false.

That said, if you define an ID in a state file defined in the top.sls, and then also include that state file in a different state file defined in top.sls, this should not be producing conflicting ID errors.

(Edited for clarifications)

@thatch45

This comment has been minimized.

Show comment
Hide comment
@thatch45

thatch45 Dec 27, 2013

Member

This original issue is still fixed, the issue brought up here is a separate issue now tracked in #9464

Member

thatch45 commented Dec 27, 2013

This original issue is still fixed, the issue brought up here is a separate issue now tracked in #9464

@thatch45 thatch45 closed this Dec 27, 2013

@dhs-rec

This comment has been minimized.

Show comment
Hide comment
@dhs-rec

dhs-rec May 8, 2015

Contributor

I don't think it's fixed. I see it now on 2014.7.x:
Detected conflicting IDs, SLS IDs need to be globally unique. The conflicting ID is 'foobar' and is found in SLS 'development:foo/bar' and SLS 'development:foo.bar'
when I have foo/bar in top.sls and "include foo.bar" somewhere else. Seems the difference comes from "/" vs. ".". Or do I need to put "foo.bar" into top.sls, too?

Contributor

dhs-rec commented May 8, 2015

I don't think it's fixed. I see it now on 2014.7.x:
Detected conflicting IDs, SLS IDs need to be globally unique. The conflicting ID is 'foobar' and is found in SLS 'development:foo/bar' and SLS 'development:foo.bar'
when I have foo/bar in top.sls and "include foo.bar" somewhere else. Seems the difference comes from "/" vs. ".". Or do I need to put "foo.bar" into top.sls, too?

@dhs-rec

This comment has been minimized.

Show comment
Hide comment
@dhs-rec

dhs-rec May 8, 2015

Contributor

OK, using "." in top.sls works.

Contributor

dhs-rec commented May 8, 2015

OK, using "." in top.sls works.

@DanielYWoo

This comment has been minimized.

Show comment
Hide comment
@DanielYWoo

DanielYWoo Nov 19, 2017

what if I have "mysql" in top.sls

  'L@serv01, serv02, serv03':
    - rabbitmq

Then in rabbitmq.sls I must ensure user and groups like this

# users and groups
rabbitmq:
  group.present:

rabbitmq:
  user.present:
    - groups:
      - rabbitmq

I will have three duplicate global IDs?

DanielYWoo commented Nov 19, 2017

what if I have "mysql" in top.sls

  'L@serv01, serv02, serv03':
    - rabbitmq

Then in rabbitmq.sls I must ensure user and groups like this

# users and groups
rabbitmq:
  group.present:

rabbitmq:
  user.present:
    - groups:
      - rabbitmq

I will have three duplicate global IDs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment