-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Windows Package Core Resource/Provider #2
Conversation
👍 |
@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? |
|
||
This would be the default package provider on windows, so you would use the 'package' resource and wouldn't need a shortcut. | ||
A windows\_package shortcut resource would be overridden by the package LWRP in the windows cookbook, causing confusion if you were | ||
still using other parts of the windows cookbook. |
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.
``` | ||
|
||
### DISMPackage | ||
Shortcut Resource Name: `dism_package` |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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? |
### 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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... |
#### Examples | ||
|
||
``` | ||
windows_package "PuTTY version 0.60" do |
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 to be clear, this would be "package" and not "windows_package",correct?
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, 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).
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). |
@miketheman I don't see
|
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. |
The default provider can be accessed with just package instead of windows_package, which is cruft from the documentation from the existing LWRP.
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. |
So one other thing I'd like to see here are some ideas on implementation. Here are questions that I have:
|
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. |
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. |
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:
Maybe in addition having a 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 |
I think the attributes would be the same as the resource in the 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. |
Goodness to me -- will be great to add the msu, msp, and even mst support in the future. |
RFC: Windows Package Core Resource/Provider
# This is the 1st commit message: This commit proposes an RFC to replace the existing RFC-075 (Multiple Policy Files and Teams) Signed-off-by: Jon Cowie <jcowie@chef.io> # This is the commit message #2: More specification details added Signed-off-by: Jon Cowie <jcowie@chef.io> # This is the commit message #3: Add more specification details and problems section Signed-off-by: Jon Cowie <jonlives@gmail.com> # This is the commit message #4: Add path parameter to git source Signed-off-by: Jon Cowie <jonlives@gmail.com>
No description provided.