Per Catalog force_install_after_date

[Nathaniel Strauss]

I’m proposing a new key named per_catalog_force_install_after_date containing the catalog and associated force_install_after_date. This would take precedence over the non-catalog level force_install_after_date key. It would be opt-in, not impacting existing setups.

Consider an autopromote workflow like Gusto’s open source solution (https://github.com/Gusto/it-cpe-opensource/tree/main/autopromote). While some autopromote workflows only move pkgsinfo through catalogs, this one includes a force_install_after_date which is progressively pushed further into the future as promotion occurs. That also means computers which haven’t installed software by the previously required date get their deadline moved too.

For example, a new pkginfo for Firefox is created. An autopromote workflow runs and adds it to the development catalog with a force_install_after_date one week in the future. A week later autopromote runs again and adds that Firefox version to the testing catalog with a new force_install_after_date another week into the future. Since there’s only one force_install_after_date, any computer using the canary catalog which didn’t install Firefox already gets 2 weeks instead of 1 before the force_install_after_date deadline.The problem compounds as the pkginfo moves through more catalogs.

I’d like the option to have individual force_install_after_date for each catalog to ensure dates stay consistent as pkginfo are promoted. If there is no matching date for a specific catalog, Munki falls back to force_install_after_date. The new key would either be a dictionary or an array of dictionaries like below.

Example pkginfo keys

<key>catalogs</key>
<array>
    <string>development</string>
    <string>testing</string>
    <string>production</string>
</array>
<key>per_catalog_force_install_after_date</key>
<dict>
    <key>development</key>
    <date>2024-03-14T13:00:00Z</date>
    <key>testing</key>
    <date>2024-03-21T13:00:00Z</date>
    <key>production</key>
    <date>2024-04-04T13:00:00Z</date>
</dict>

Or

<key>per_catalog_force_install_after_date</key>
<array>
    <dict>
        <key>catalog</key>
        <string>development</string>
        <key>force_install_after_date</key>
        <date>2024-03-14T13:00:00Z</date>
    </dict>
    <dict>
        <key>catalog</key>
        <string>testing</string>
        <key>force_install_after_date</key>
        <date>2024-03-21T13:00:00Z</date>
    </dict>
    <dict>
        <key>catalog</key>
        <string>production</string>
        <key>force_install_after_date</key>
        <date>2024-04-04T13:00:00Z</date>
    </dict>
</array>

My guess is many orgs don’t use force_install_after_date often, and if/when they do, take the approach of setting one date for all catalogs further into the future. If it takes 4 weeks to promote through all catalogs, the force date is immediately after those 4 weeks or even later. However, for orgs with stricter SLAs or compliance requirements, I see the advantage in more tightly controlling force_install_after_date. Definitely heavier handed, but with better assurances software is installed by a specific date.

I’m open to contributing the work myself. Not asking anyone else to take it on. Curious what people’s thoughts are and if they would find this to be a useful feature.

[Gregory Neagle]

Couldn’t this (rather “corner-case”) problem be solved with no code changes to Munki by having separate pkginfo files per catalog?

If you have development, testing, and production catalogs, there could be up to three pkginfo files, each describing the same installer item. The difference between the pkginfo files would be the catalogs list and the content of the force_install_after_date key.

(I’m also curious how many admins are using more than testing->production [IOW, two catalogs] for their testing workflows. I suspect very few are using deployment->testing->production [three catalogs], and still fewer more than three catalogs in a promotion flow)

-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 view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/e9aa965d-ca5a-4f72-818a-e9af375c66ddn%40googlegroups.com.

[Nathaniel Strauss]

I did consider that, but thought it would get messy quickly. Is there another situation or feature where multiple pkginfo would be used? It feels like a bad pattern. In my mind there should be one pkginfo defining behavior for a specific software version. Spreading the same release over multiple pkginfo, given three catalogs, and maybe multiple supported architectures, means a lot of sprawl. I'm concerned it would be difficult to manage, even programmatically, and make room for mistakes.

> (I’m also curious how many admins are using more than testing->production [IOW, two catalogs] for their testing workflows. I suspect very few are using deployment->testing->production [three catalogs], and still fewer more than three catalogs in a promotion flow)

I'm curious on this point too. Is there a wide enough audience for my proposed feature to be useful? One of the main reasons to use Munki is to not deploy direct to production, and I think that pattern is common. Is it as common to have three or more catalogs? 

[Kevin M. Cox]

We basically have three catalogs:

1. Development, which is not in the autopromote cadence.

2. Canary, where things go right after being added via AutoPkg.

3. Production, which is the terminal catalog for autopromote.

While theoretically I understand the problem being described, it isn't one I've ever been concerned with. Most apps don't release quick enough fall into that window and for the one that does, we enforce Chrome updates via managed browser policies.

For each organization this will all come down to how quickly items autopromote to "production" and how many days from that promotion the force install date is. The longer an item sits in "testing/canary" and the further out the force install date is (3 days vs. 30 days) the more likely this will be a problem.

~ Kevin

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/e0ce9692-cba6-4951-a7c7-16df0e2c1a6fn%40googlegroups.com.

[Gregory Neagle]

Some more thoughts on this topic:

- From a Munki client’s POV, pkginfo files don’t exist — only catalogs exist. It’s an implementation detail that admins create pkginfo files and use `makecatalogs` to “compile” those pkginfo files into catalogs. So it’s perfectly OK to have different pkginfo files for different catalogs. If you don’t like the idea of managing multiple pkginfo files for one item, perhaps you want to modify `makecatalogs` to create different items in different catalogs based on the contents of a pkginfo. This would avoid changing client-side logic. Or maybe a `makecatalogs` pre-processor…

- Since the very nature of a development->testing->production workflow implies that some updates might be rejected and not ever make it to production, it seems odd to me to have “force_install_after_date” for items not yet in production: you might force some users to install an update that later you decide not to deploy to production at all. I’d personally expect _no_ “force_install_after_date” attribute until the item is moved to production.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/e0ce9692-cba6-4951-a7c7-16df0e2c1a6fn%40googlegroups.com.

[Nick McSpadden]

We get around this by establishing a specific force install date on a target day of the month (second Tuesday) - and the autopromote script applies this force date to the newest version of every item in a given catalog (typically our production shard catalogs). I feel like this problem could also be solved without Munki changes, per se, by changing the rolling logic of the autopromote window.

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/32B27465-F9A9-4CA2-BF6E-23B6D7DC40D0%40mac.com.

--

--
Nick McSpadden
nmcsp...@gmail.com