RFC: Windows Package Core Resource/Provider

[btm]

No description provided.

[sethvargo]

👍

[adamedx]

@btm, can you some example usages? In particular, I'm interested in people using "package" as the resource. Will all the windows_package examples at http://docs.opscode.com/lwrp_windows.html#id8 have direct analogs?

[adamedx]

So which installer types does this package handle -- msi + various flavors of exe?

[btm]

Yeah, "package" on windows would be the same as the windows_package resource in the Windows cookbook.

[juliandunn]

I still have reservations about calling things that you install via DISM or Server Manager to be "Packages". That's not how Windows folks think of them: they are features or roles.

I know there is a reservation about introducing a top-level "feature" resource but I feel like that's the right thing to do.

[adamedx]

We should probably get some feedback from a few customers on the rfc regarding your point @juliandunn .

My take is that Windows actually attempts to make these things all look the same -- for example, software patches, installed + available software, and Windows features (through the "Turn Windows features on or off" item) are all shown in the same gui app, Add / Remove programs (appwiz.cpl). My insider claim on the reason that these things do have different guis (dism and add / remove programs for windows featuers, server manager roles, msi's, etc.) is not because these are conceptually different, it just reflects product group boundaries (e.g. server manager was explicitly developed by the Windows Server group separately from concepts promoted by the core Windows group).

Ultimately if we talk to some customers and they are more comfortable with these as separate resources, that's something we need to take into account. I do think having similar idioms across *nix and Windows is preferable, but if it causes usability issues I could sacrifice it.

[juliandunn]

I totally agree @adamedx , let's bounce it off a few key Windows customers and see if they'd find that confusing.

[sersut]

I agree with the idea of getting feedback from windows folks.

With intuition, I agree with @juliandunn that we should call them out Features and Roles. Under the covers they might be using the same provider but there is no reason against having two resources exactly same with different names if that's along with how customers are thinking about them.

[miketheman]

Is there ever a case where there is a passivity that defining a package name, say 'mysql', would work the same way across multiple platforms?

[sersut]

IMO we can ship v1 with a subset of the package types listed in here.

All of these types require specialized logic for omnipotency across chef runs (i.e. we should have specific logic to check if a package is installed and doing that for a custom package type is hard without any user input).

I'd vote to ship our v1 with features, roles and MSIs.

[btm]

This text describes the functionality of the existing providers. Unless there's a critical problem with any of them, I would not want to move the existing providers to core chef and reduce their functionality.

The existing windows_package LWRP runs the program specified, and tries to guess at what flags it should pass for that installer to run in a silent/unattended mode. "custom" is for the user specifying the flags.

[adamedx]

I'm not too worried about reduced functionality in the short-term @btm -- anyone needing something we didn't take over can still use the Windows cookbook. MSFT views anything that's not an MSI as "bad", so in that sense if we focus on MSI for v1, we'll have handled the most important case. MSI can actually support idempotence. And then feedback can let us decide if it's worth it to take in the other stuff in future versions. And testing the other types is not going to be fun -- we'll be able to get most customers in good shape if we focus on the most important scenario, ship it, and then add functionality as needed.

My only caveat to the advice I am giving -- RubyInstaller does not seem to use MSI packaging. :( So whatever format it uses (inno?) could be one of the first we do after MSI.

[sersut]

Here are some topics which are not covered in this RFC which IMO we should have a plan for:

1-) Dependencies across roles / features: Attempting to enable a windows feature or role will most likely require for other roles and feature to be enabled as well. Maybe we can have a flag similar to the "recursive" flag of the file resource that will specify if the dependencies should also be enabled when enabling a role or a service.

2-) Feature / Role sub elements: Windows exposes sub-elements for features and roles. When enabling IIS some of the sub-features are enabled by default but some are not. We should have a mechanism for users to specify which sub-features they want to be enabled incase they want to enable a subfeature that is not included in the defaults.

3-) Role / Feature configuration: When enabling a role one can use a file which specifies some configuration attributes to the role or feature. IMO we should expose a mechanism for people to change the default config of features or roles. This is somewhat a complicated area because providing omnipotency at the role config level is hard. For e.g. I can specify where the virtual machines should be stored by default while enabling Hyper-V role in the windows package resource. However users should not expect to execute the same resource and change the configuration of roles / features after changing the config parameter supplied to the role. DSC is the solution to this problem but I don't think we need to solve this problem in v1.

4-) Upgrade scenario is not discussed in this document. Theoritically users can use a different MSI with the same product ID to upgrade an existing installation. Not sure if this is a problem worth solving. Another area we might want to gather some feedback IMO.

5-) A very big win will be the ability to install hotfixes. Again this is an area for some customer feedback. If enterprise folks want to use chef to distribute hotfixes this feature would be more important that the exotic package types such as inno / install shield...

[adamedx]

So to be clear, this would be "package" and not "windows_package",correct?

[btm]

Yeah, this is from copying the examples from the existing windows_package LWRP. I don't think we would want a windows_package shortcut resource because it would conflict with the existing windows cookbook (especially if we implemented this with reduced functionality).

[adamedx]

Regarding some earlier feedback from @sersut, I agree that we should be able to manage patches -- I would start with just msp's at first if our focus is on msi's. We could treat the package a specific way based on the file extension (msp or msi).

[btm]

@miketheman I don't see package "mysql" ever working on Windows because we don't have a traditional package management system there that can fetch packages. Since you've got to fetch the package yourself it tends to be more of a:

package "mysql" do
  source "Z:\mysql-installer-community-5.6.15.0.msi"
end

[adamedx]

Regarding other feedback on roles / features: I think for v1 we should not go beyond what's in the existing windows cookbook implementations for roles and features. I do think we should have a plan, and perhaps this RFC is the right place for it, or maybe roles and features should have their own rfc.

I do agree in general though that we should do the subfeature specification and configuration capabilities.

[adamedx]

With regard to use of productid's, I can see this being useful down the road once there is a standard package repository for Windows. I would like to see us name the package with a canonical name, possibly a productid guid, though that's not user friendly. Additionally, we could take update id's (i.e. id's from Windows Update) -- this capability will actually be very valuable since people often would like to ensure a specific patch is installed.

[adamedx]

So one other thing I'd like to see here are some ideas on implementation. Here are questions that I have:

1. For msi's, how do we ensure idempotence? Direct calls to MSI? If so, what api layer -- the MSI WMI provider or MSI Win32 API?
2. Should we also use the API (rather than MSIEXEC) to install the msi?
3. Will we need to read the package to retrieve the product id in order to see if the product is already installed?
4. If we just call msi to install the package without checking to see if it is already installed, how do we know that an installation happened (vs. nothing because it is already installed) -- will the msi installation command return a "product_already_installed" return code so we know whether to say that the resource is updated?
5. If we do something with the above, will we be able to implement whyrun?

[adamedx]

So even if we don't do the non-msi installers at first, the reason for doing this is to bake the silent install logic into the cookbook so you don't have to use the execute or script resources to run the install. This is most useful if we automatically detect the installer type -- then people can just take .exe's for software like 7zip, rubydevkit, etc. and use the package resource without having to do research to look up flags for doing silent installs.

[btm]

I've removed feature and roles from this RFC, with the expectation we will provide support for those in another resource (new feature resource).

Also explicitly kicks the can down the road for designing other things like MSU support and an idempotent upgrade. I'd like to do this work more incrementally.

[sersut]

Sweet! Love it. 👍

I think having a section that lists the attributes for this resources would make it more clear. From what I can tell from the initial section the attributes we have in mind are:

name, installer_type, checksum, timeout, success_codes

Maybe in addition having a install_parameters section would be helpful. You can pass in parameters to MSI installs (e.g. http://devopscloud.net/2011/03/23/dissection-of-a-chef-recipe-or-two-for-windows/) An example of it would be:

windows_package '7-Zip 9.20 (x64 edition)' do
  source 'http://downloads.sourceforge.net/sevenzip/7z920-x64.msi'
  action :install
  install_parameters ["/qn", "-config", "#{cache_path}\\7zip.xml" ]
end

[btm]

I think the attributes would be the same as the resource in the cookbook:

• package_name
• source
• installer_type
• options
• version
• returns (success_codes in the windows cookbook)

Source in the cookbook supports taking a URL, so it also has a 'checksum' attribute. Ideologically I think we don't support URLs, since that's what remote_file is for. I suppose it is more convenient though.

[adamedx]

Goodness to me -- will be great to add the msu, msp, and even mst support in the future.