re: multiple catalogs per client, or per package?

[Dan Bibb]

I have my Munki environment set up so that each machine has it's own manifest, and i have two main catalogs: Testing, and Production. Each clients manifest is set to receive installs from either the Testing or the Production catalog, but not both.

Regarding the most recent Munki 2.8 release, since only admin and core pkgs have been updated, should I keep the other two, munkitools and the launchd pkgs as both Testing AND Production? 

That's one example, but I think I will have other scenarios that call into question the same thing.

So it seems I need to either have some pkgs be in both catalogs, or some clients manifests set to both catalogs. Is that correct? Or am I way off the mark here?

[Gregory Neagle]

My testing clients have manifests with catalogs like this:

<key>catalogs</key>

<array>

    <string>testing</string>

    <string>production</string>

</array>

This way the testing catalog is checked first, but for any item that is not in the testing catalog, Munki will check the production catalog.

This allows me to have only a small number of items in the testing catalog at any one time -- those we are actively testing. Once we're happy with the new version of an item, it is moved to the production catalog.

-Greg

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To post to this group, send email to munki-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/a113fac2-27b6-450f-a1c1-b87348481972%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Bibb]

That's what I was doing initially, but I started debating whether that was the best way to do it.

Thank you for the quick response!

[Gregory Neagle]

Note that this arrangement can sometimes lead to unexpected consequences if you don't really understand how Munki searches multiple catalogs to find items.

Let's say you are testing Foo-2.0, but while testing, Foo-2.1 comes out and you import it and add it to testing. Now the testing catalog has both Foo-2.0 and Foo-2.1, but Munki does the right thing and your testing clients get Foo-2.1.

Later, testing is complete, and you move Foo-2.1 to production. You aren't intending to deploy Foo-2.0 at all, so you ignore it and leave it in the testing catalog.

Clients checking only the production catalog now get Foo-2.1, but you are surprised when new testing clients get Foo-2.0.

This, of course, is because Munki is checking the testing catalog first, sees Foo, and chooses the highest version IN THE FIRST CATALOG IN WHICH IT IS FOUND.

To avoid this situation, make sure you either promote or remove items in your testing catalog once testing is complete -- don't leave them hanging around in there, especially if you have no intention of deploying them.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/4705a40d-fd74-4f70-a4f8-35e20ce79928%40googlegroups.com.

[Dan Bibb]

Duly noted Greg, thanks again.