MODULES-2861: run stages limitation added to the documentation.

[ryayon]

No description provided.

[daenney]

I would like to use a different word than conflict. In Puppet lingo that's normally associated with resource conflicts, and that's not the case. It doesn't really conflict in that sense, it just causes all virtual resources to be realised at that point because of the unfortunate side-effect that collectors <||> cause realisation.

[ryayon]

I understand.

What about:
Be aware that this example will realize all your virtual package resources. Adapt it to your environment.
?

[daenney]

👍. Though this now poses the interesting question if people will understand what we mean with "realise". I think it's good enough for now though, we can clarify it further if it comes up often.

[daenney]

@jbondpdx Any thoughts on the wording now?

@ryayon I'm going to have to ask you to squash this down to a single commit.

[ryayon]

@daenney Not sure I did well for the git squash.
Let me know.

[daenney]

@ryayon I'm seeing 4 commits now. We should be down to 1 from 2 but it multiplied so I think that went wrong 😄.

[ryayon]

@daenney I completely messed up.
I did a hard reset, then you should get only one commit, although not the best way.

[daenney]

That's alright, as long as we get the intended end result. Thank you!

[petems]

Do we want to restrict this to apt packages only? Otherwise other providers such as gems would be affected.

Class['apt::update'] -> Package <| provider == 'apt' |>

[ryayon]

I agree with you, but the way you realize the resource means that you have to specifically provide the parameter provider?

[petems]

I'm not sure I follow. Using the spaceship collector without specifying the provide will collect all package resources in the catalogue, which you probably don't need to do, as it will collect gems, npm packages etc.

[ryayon]

I mean,

1. if you are on a Debian-like OS, by default, Puppet will use apt to manage packages.
2. if you specify provider=apt, it will also use apt to manage packages.

Once you use:

Package <| provider == 'apt' |> 

, will it realize all resources or only the 2nd case resources?

[petems]

Ok, I understand what you're saying now 👍

99% sure it's 2, as I've done this with yum_repo resources before, but I can check

[ryayon]

I will try to check also.

[petems]

Yeah, it's 2, so that's the correct change 👍

[jbondpdx]

I'm 👍 on the language.

[daenney]

Alright. Then I'll wait on the change that @petems has suggested and merge it.

[ryayon]

Done

[daenney]

I feel that this has gone wrong:

Limitations

This module is tested and officially supported on Debian 6 and 7 and Ubuntu 10.04, 12.04, and 14.04. Testing on other platforms has been light and cannot be guaranteed.

This module is not designed to be split across stages. If you want to ensure that apt update is run before all packages, add a proper dependency like this:

Class['apt::update'] -> Package<||>
Be aware that this example will realize all your virtual package resources.

Adapt it to your environment.

Adding new sources or PPAs

If you are adding a new source or PPA and trying to install packages from the new source or PPA on the same Puppet run, your package resource should depend on Class['apt::update'], in addition to depending on the Apt::Source or the Apt::Ppa. You can also add collectors to ensure that all packages happen after apt::update, but this can lead to dependency cycles and has implications for virtual resources.

Class['apt::update'] -> Package <| provider == 'apt' |>

Now we have two examples with different collectors.

[ryayon]

Indeed, I didn't see that.
Maybe, we can just add:

This module is not designed to be split across stages.

and update the current Class['apt::update'] -> Package<| |> to Class['apt::update'] -> Package <| provider == 'apt' |>

[daenney]

Sounds good to me.

[ryayon]

Pushed again.
Let me know.

[daenney]

Off it goes. Thank you for the work!

[ryayon]

Sounds good.
Thank you for your help.