RFC: Windows Package Core Resource/Provider #2
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,84 @@ | ||
| # Windows Package Resource and Providers | ||
|
|
||
| Proposal for moving windows\_package and windows\_feature LWRPs from the windows cookbook into core Chef. | ||
|
|
||
| Chef internal PBI: [OC-5114](https://tickets.corp.opscode.com/browse/OC-5114) | ||
|
|
||
| Installing packages on Windows usually means passing a flag to the installer to indicate it is an unattended installation. | ||
| There are a number of standard installation packages which can specified or detected in the windows cookbook, or the user can specify the correct flags. | ||
|
|
||
| Windows also supports installing features (formerly components) which are special packages that come with windows. | ||
| Features map closely to the package resource in Chef, so we can make additional providers rather than add a core 'feature' resource. | ||
|
|
||
| ## New Core Resources/Providers | ||
|
|
||
| ### WindowsPackage | ||
| Shortcut Resource Name: `none` | ||
|
|
||
| This would be the default package provider on windows, so you would use the 'package' resource and wouldn't need a shortcut. | ||
|
|
||
| If we used a shortcut resource named windows\_package it would be overridden by the package LWRP in the windows cookbook, causing confusion if you were | ||
| still using other parts of the windows cookbook. | ||
|
|
||
| #### Examples | ||
|
|
||
| ``` | ||
| windows_package "PuTTY version 0.60" do | ||
|
There was a problem hiding this comment. So to be clear, this would be "package" and not "windows_package",correct? There was a problem hiding this comment. 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). |
||
| source "http://the.earth.li/~sgtatham/putty/latest/x86/putty-0.60-installer.exe" | ||
| installer_type :inno | ||
| action :install | ||
| end | ||
| ``` | ||
|
|
||
| ``` | ||
| windows_package "VLC media player 1.1.10" do | ||
| source "http://superb-sea2.dl.sourceforge.net/project/vlc/1.1.10/win32/vlc-1.1.10-win32.exe" | ||
| action :install | ||
| end | ||
| ``` | ||
|
|
||
| ### DISMPackage | ||
| Shortcut Resource Name: `dism_package` | ||
|
There was a problem hiding this comment. So I could do something like this, right? package 'IIS' do There was a problem hiding this comment. This would be either: Or: Is that too obtuse? I think it's not obvious. That is, if I sat down to wonder how to install IIS when I normal click on features bits, I'm probably not aware of DISM. But I think we solve that with documentation. Wildly guessing at resource names rarely works anyway. There was a problem hiding this comment. 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. There was a problem hiding this comment. 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. There was a problem hiding this comment. I totally agree @adamedx , let's bounce it off a few key Windows customers and see if they'd find that confusing. There was a problem hiding this comment. 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. |
||
|
|
||
| #### Examples | ||
| ``` | ||
| dism_package "IIS" | ||
| ``` | ||
|
|
||
| ``` | ||
| package "IIS" do | ||
| provider Chef::Provider::Package::DISM | ||
|
There was a problem hiding this comment. ok, yeah, I like this -- I just say package, and swap the provider. After that, if I've used package with other providers, I feel comfortable with it here. |
||
| action :install | ||
| ``` | ||
|
|
||
| ### ServerManagerPackage | ||
| Shortcut Resource Name: `server_manager_package` | ||
|
|
||
| #### Examples | ||
|
|
||
| ``` | ||
| server_manager_package "Web-Server" | ||
| ``` | ||
|
|
||
| ``` | ||
| package "Web-Server" do | ||
| provider Chef::Provider::Package::ServerManager | ||
| action :install | ||
| ``` | ||
|
|
||
| ## Windows Cookbook | ||
|
|
||
| The existing windows cookbook contains two relevent LWRPs, package and feature. | ||
|
|
||
| ### Resources | ||
| * package | ||
| types: msi, inno, nsis, wise, installshield, custom | ||
| examples: putty-0.60-installer.exe, 7z920-x64.msi, 'Google Chrome' | ||
|
There was a problem hiding this comment. 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. There was a problem hiding this comment. 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. There was a problem hiding this comment. 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. |
||
| * feature | ||
| types: dism, servermanagercmd | ||
| examples: DHCPServer, TelnetClient, TFTP, CertificateServices | ||
|
|
||
| ### Providers | ||
| * package: handles different installers with a set of default flags for the options attribute | ||
| * feature\_dism: installs features using dism.exe | ||
| * feautre\_servermanagercmd: installs features using servermanagercmd.exe | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So which installer types does this package handle -- msi + various flavors of exe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, "package" on windows would be the same as the windows_package resource in the Windows cookbook.