Skip to content
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

Should we complete windows ohai files? #203

Open
Annih opened this issue Feb 4, 2016 · 11 comments
Open

Should we complete windows ohai files? #203

Annih opened this issue Feb 4, 2016 · 11 comments

Comments

@Annih
Copy link
Contributor

Annih commented Feb 4, 2016

Hello,

TL;DR: Do you think it would be usefull to have more specific windows ohais (i386, x64, CORE)? - could be extended to other platforms

I'm currently adding test to one of my cookbooks, and wanted to validate them using most of the windows fauxhai already available. Doing so I encounter a small issue regarding the machine architecture... sometimes I need to test theoric behavior on specific windows "setup" - 32/64bit, CORE.
I also faced the absence of older versions of windows e.g. 7 or Vista/Server 2008.

It's feasible to take one existing fauxhai and transform it to another version by overriding specifics attributes, but it's adding complexity to the tests.

Here is an updated list of possible fauxhai files - bold for already existing versions:

Name Version Windows Server Server Core
2008 6.0.6001 ✖️
7/2008R2 6.1.7600 ✔️ ✔️
8/2012 6.2.9200 ✔️
8.1/2012R2 6.3.9600 ✔️ ✔️
10 v1507 (TH1) 10.0.10240 ✖️ ✖️
10 v1511 (TH2) 10.0.10586 ✖️ ✖️
10/2016 v1607 (RS1) 10.0.14393 ✔️
10 v1703 (RS2) 10.0.15063 ✔️ ✖️ ✖️
10/2016 v1709 (RS3) 10.0.16999 ✖️

Some of the windows version I listed are old, I first chose to start with 2003R2 generation because fauxhai already support it, but hey 2003R2 is not supported by chef :)
Current fauxhai represents 7 / 19 possibilities, but maybe we don't need to support all of them - I already skip the itanium arch :)

If this issue gathers enough interest, I would be able to provide most of the missing fauxhai files; then we should also define a naming convention e.g. <version>-<arch>[-CORE]

So for people who read everything, what do you think?

cc: @aboten

Update1: removed 32bits version as they are not supported by Chef
Update2: added Windows 10 & Server 2016 versions

@coderanger
Copy link
Collaborator

We don't support Chef on 32-bit Windows so adding it here seems a bit pointless. Not sure what you mean by "Core x64".

@Annih
Copy link
Contributor Author

Annih commented Nov 6, 2017

Wow thanks @coderanger for looking at this issue, I almost forgot I created it.
Ok for the 32-bit platforms, lets get rid of them.

By Core x64 I mean Windows Server in its Core version, because Windows Server does not support 32bits since 2008R2 the x64 part is useless :). When I was playing with it (2008R2 Core) I discovered that my code needed to handle it properly, based on some Ohai info.
The issue I faced at this time, was that there were no Fauxhai for this platform, so I created this issue.

Starting with Windows Server 2016, Microsoft introduced the Nano version, but I didn't play with it, so I don't know how it integrates with Chef.

With Windows Server 2016 RS3, Microsoft kept the Nano & Core versions, but removed the normal one, so next fauxhai data for Windows Server 2016 will have to handle the Core version anyway :D

I'm going to update my original issue message to take your feedback into account.

@coderanger
Copy link
Collaborator

That would all depend on how Ohai deals with Windows Nano and Server Core, I would have assumed that was a new platform, not a version on an existing one. I don't think we have Nano-compatible installers for Chef, so utility there is probably pretty minimal but whatever data Ohai produces we would be happy to add.

@Annih
Copy link
Contributor Author

Annih commented Nov 6, 2017

We could consider Server Core as a new version, but how to represent that in Chef? Changing this might have some side effects for existing environments, IMHO this is not worth it.
Currently you can use the ::Chef::ReservedNames::Win32::Version.core? helper to determine in which "version" you are, it working fine - even if I prefer the ::Windows::VersionHelper.core_version? library from the windows cookbook.

Core servers may have different capabilities and features names but are pretty much the same as normal servers. The only difference I can see for fauxhai is the kernel.os_info.operating_system_sku attribute.

@coderanger
Copy link
Collaborator

That discussion is for Ohai, not here. Whatever Ohai does, Fauxhai will follow.

@Annih
Copy link
Contributor Author

Annih commented Nov 6, 2017

Now that I updated the list of available Windows versions, I think my suggested naming convention is obsolete 😄
How to expose all the Windows 10 versions?

  • Using the code name - TH1, TH2, RS1, RS2, RS3
  • Using the date/version - 1507, 1511, 1607, 1703, 1709
  • Using the build - 10240, 10586, 14393, 15063, 16299

@coderanger
Copy link
Collaborator

Again, platform and platform version naming is not up to Fauxhai. We match the output of Ohai for the most part. You will have to take it up over there.

@Annih
Copy link
Contributor Author

Annih commented Nov 6, 2017

You miss understood me, I'm no talking about changing anything in Ohai values.
Currently if I want to get Windows Server 2016 fauxhai data, the platform is windows and the platform_version is 2016.

I want to setup a naming convention in Fauxhai to easily select the desired and precise platform data in a coherent way.

For instance I would still use the windows platform, but maybe I should use Server-2016-RS1 as desired platform_version, or Server_2016_1607.
Or maybe I should use a different platform windows_server and precise 1607 as platform_version

Are my intentions clearer?

@coderanger
Copy link
Collaborator

We don't really have the resources to commit to maintaining more dumps than we already have. If you need more specific data, it's probably something that should be in your unit tests themselves.

@Annih
Copy link
Contributor Author

Annih commented Nov 6, 2017

Ok that was my original question. Is it interesting for Chef and the community that we provide all dumps?
Windows has currently only 9 dumps over the 19 supported versions. CentOS has more than 30 dumps :P

If some of the missing dumps were provided, would they be accepted?

@tas50
Copy link
Contributor

tas50 commented Nov 6, 2017

@Annih We could certainly dump more versions. We have a ton of Linux dumps because for a week I installed every single one of those and ran fauxhai on it. It took a REALLY long time, but it's orders of magnitude faster than installing Windows. I dumped several versions of Windows, but it's certainly not all there. I'll take a look at what Chef / Microsoft supports and see if there's anywhere we could fill in some gaps. We won't be dumping Windows 2008, or Windows 8 though since those aren't supported platforms. We should make sure we have the latest Windows 10 though and we should probably version it on the build numbers since MS has gone to a bit of a rolling release model now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants