Merging autopkg and automunkiimport about autopkg HOT 8 CLOSED

Currently, the makecatalogs step of automunkiimport has access to the results of any recipes run in the session, and therefor "knows" if anything new has been imported into the Munki repo. It then runs makecatalogs only if needed.

If we move this functionality out of the new unified autopkg tool and into a recipe, a complication is that recipes don't know anything about other recipes. A makecatalogs recipe would always run makecatalogs whether is was needed or not.

It might be possible to give recipes access to the run results of previous recipes (run in the same autopkg session). Is this worth the complexity? Is there another way to approach this?

from autopkg.

As I continue to talk to myself here:

I now have automunkiimport write its run_results array to disk in a known location after each recipe run. The MakeMunkiCatalogs recipe can read this array and look through the results to determine whether or not to run makecatalogs.

I think much of the other Munki-specific functionality in automunkiimport can now be factored out into recipes; this should make merging the tools and making the resulting tool more generic/flexible much easier.

from autopkg.

I think I'll create a third tool to demonstrate all this so we don't yet break the current functionality of autopkg and automunkiimport. Its name shall be "auto". :)

from autopkg.

Making these tasks separate recipes is a pretty good compromise for simplicity's sake, I think. It's not hard for any kind of automated run setup like Jenkins to just bookend its recipe list with the appropriate Recipes.

Running interactively it's less convenient, but maybe a defaults key that could be supported to add arbitrary recipes to runs, keyed by kind, without us needing to add special cases to the command-line tool:

AutoRunAdditionalRecipes: {
  munki: {Pre: [MountMunkiRepo],
          Post: [MakeMunkiCatalogs, UnmountRepo]
         }
  pkg: {Pre: [],
       Post: [CopyPackageOutputToMyOutputDirectoryIveSetInAnOverride]
       }
}

This way if you never want to build catalogs, or always want to run some other custom reporting recipe, etc. you've come up with, you're free to do it here.

These preferences are unfortunately not condusive to editing with defaults. 😠

Another idea that's more OO, but this gets back into more fundamental architecture I'm not sure we want to revisit right now:

These behaviors might be better suited to a different kind of class like a "Runner," belonging to a given action, that can augment the existing processing chain currently being done in autopkg/automunkiimport.

A Runner could implement pre- and post-run actions, or other types of actions that the core tool might want to support. A MunkiRunner can mount and run makecatalogs, even if this is effectively just running a processor. A Runner could also support additional defaults preferences and/or command switches.

This is undoubtedly more complex. But, it might make it easier to extend and customize the behavior of the tool.

from autopkg.

As I continue down this path, I'm finding the filename conventions for distinguishing "package"-style recipes from "munki"-style recipes to be causing some issues.

A specific example:

autopkg/recipes contains a "Firefox" directory, which contains "_munki.plist' and "_pkg.plist" files, containing the "munkiimport" recipe and the "make a package" recipe, respectively.

If I make an override for the Firefox/_munki.plist recipe, it gets stored in my RecipeOverrides directory as "Firefox.plist". There's no clue in the filename what kind of recipe this is an override for; I have to read the file to find that out. This is a problem when doing:

auto package Firefox

as the code to find recipes finds the override (which is a Munki recipe) and uses that, instead of skipping it and finding the Firefox/_pkg.plist recipe. This can be coded around, but makes things more complicated. It's not entirely clear what the "correct" behavior should be in this case, but it's definitely confusing!

Further, if I want to make an override for Firefox/_pkg.plist - I need to invent a different name for it, since it can't be saved in the RecipeOverrides directory as "Firefox.plist" -- that name is already taken.

I think both of those issues can be addressed by moving to defined file extensions for recipes.

Recipes should have a filename of the form:

foo.recipe

They may (and are encouraged to) further declare what "kind" of recipe they are with an additional extension, placed before the .recipe extension:

foo.munki.recipe
foo.pkg.recipe

This allows for additional types to be defined in the future:

foo.casper.recipe
foo.absolutemanage.recipe

Should overrides have the same extensions, or should they be:

foo.recipeoverride
foo.munki.recipeoverride
foo.pkg.recipeoverride

???

Or is there something even better?

from autopkg.

The 'auto' tool is shaping up quite nicely I think -- are there any reasons not to remove the current autopkg and automunkimport tools and replace them with auto (renamed autopkg)?

from autopkg.

Let's do it!

from autopkg.

Done: 6096cc2

from autopkg.