Support for GuestOS ID / Family

[akutz]

This patch adds support for specifying the guest operating system's ID and family.

[aruneshpa]

Accidental deletion of text?

[aruneshpa]

Do we also need to specify VirtualMachineGuestOSFamily type for all these consts, or is this Golang magic that automatically assigns them the types? Either way, I would vote for being explicit in the name of readability. (Same for Guest OS Identifiers)

[akutz]

We do not. I actually think repeating it makes it harder to follow. Go supports implicit typing in const blocks by referring to the last, non-empty, explicit type in that local const block. It is how iota and enums work in Go.

I'm tired of you being right so much lately 😃 The above is what I was going to say, and then I decided to triple-check. It turns out all the blogs I've ever read about iota get typing wrong. The above language spec refrence never states that types are implicit from the previous, non-empty type in the local const block. I even verified this in this Go playground:

package main

import "fmt"

type myEnumType string

const (
	typedHello myEnumType = "hello"
	typedWorld            = "world"
)

const (
	untypedHello = "hello"
	untypedWorld = "world"
)

func main() {
	fmt.Printf("%[1]T=%[1]s\n", typedHello)
	fmt.Printf("%[1]T=%[1]s\n", typedWorld)
	fmt.Printf("%[1]T=%[1]s\n", untypedHello)
	fmt.Printf("%[1]T=%[1]s\n", untypedWorld)
}

I expected the first two lines of output to indicate the type was main.myEnumType, but...

main.myEnumType=hello
string=world
string=hello
string=world

So yeah, I'll add it. Obviously 😃

p.s. 👍

[aruneshpa]

:-D
I actually tried this in playground by checking the type of two consts, before leaving the comment. I still thought you knew something that I didn't about Golang internals (as you often do).