(Question) Clarification of how to use a content library, some process for referencing its items, and how to get at the template values of an item

[arizvisa]

This is more of a question as it's not a bug or a feature request. There was a bug filed in issue #1012 which has been locked due to timeout. But I really couldn't quite understand how people are accomplish this. So I spent a lot of time trying to confirm how this thing is supposed to work which is this issue is sooo long, because it includes a huge explanation of my findings.

Disclaimer: I'm pretty newb at terraform and it took me a bit to find the "vsphere_content_library" and "vsphere_content_library_item" in the docs, so forgive me if it's just something that I've overlooked and there already is some way to reuse the attributes from a specific content library item.

Description

So as I understand it, the attributes of a content library item aren't available due to the content library api being very minimalistic. Issue #1012 seems to describe a workaround (?) that says to deploy a template from the content library item into a datastore, and then use that vm as a data reference in terraform. This means that a resource is unable to use any attributes from the library item and will need to manually specify its specs.

Confirming everything

The idea of the content library api being minimalistic is definitely true as its schema as exposed by govmomi (govmomi/vapi/library#Library) only gives ids, names, descriptions, and types. The schema for library items (govmomi/vapi/library#Item) also is pretty much the same.

However, from looking at documentation. It seems that the reason why the api is so minimalistic is because a content library is nothing more than a pub/sub service for monitoring changes in groups of files (an "item"). The vsphere automation sdk exposes a com.vmware.content.library interface, but its functionality only provides a way for tracking changes to library items and creating a lock (DownloadSession or UploadSession) in order to read them or write to them (respectively) without interfering with any current users.

Library Item "clients"

The base client for interacting with a content library item appears to be responsible for only exposing the "type" field, and it's apparently up to a "plugin" of some sort to be responsible for determining how to treat said group of files (as per com.vmware.content_client.Type). Referring back to govmomi's source, the "Type" field is a string and they do list the available content item types (govmomi/vapi/library#pkg-constants).

Confirming this research in govmomi's source, each content library item type is being explicitly "implemented" by whichever command is relevant to it. Grepping it yields results only in library.import and library.deploy. Because of all of this stuff, I believe VMware intends implementors to use the content library by checking the "Type" field of the item and using it to determine how one should specifically process the files contained within the item.

As only "iso", "ovf" and "vm-template" are all that's documented as valid types, as such these are the only plugins/clients that one would need to mode the file schema for. A client could then distinguish what files it should expect, and how it should extract properties from these files. In this case, an "iso" is just a straight-up file to download or reference, a "vm-template" would contain a vmx with template attributes (and a vmdk), and an "ovf" will contain an ovf file with template attributes (and also a vmdk).

Trying to get govc to work with this

Using govc to dump the model of what govmomi provides to implementors shows the following attributes. The "Type" is "ovf" so we know that we need to treat the contents of this library item as an ovf template.

$ govc library.info -dump '/LolFuzz Templates/eval-win81x86-enterprise'
[]interface {}{
    library.Item{
        Cached:           true,
        ContentVersion:   "2",
        CreationTime:     types.NewTime(time.Now()),
        Description:      "Imported as an ovf template",
        ID:               "3c12670a-6db1-4818-9d83-9b7e35d161b3",
        LastModifiedTime: types.NewTime(time.Now()),
        LastSyncTime:     (*time.Time)(nil),
        LibraryID:        "4c2253fa-877f-4512-965c-54901a191706",
        MetadataVersion:  "1",
        Name:             "eval-win81x86-enterprise",
        Size:             6177375754,
        SourceID:         "",
        Type:             "ovf",
        Version:          "1",
    },
}

Then dumping the contents of the actual library item shows that an .ovf file is contained in the group which directly corresponds to our "type". I believe that only within the content library do these names correlate, because the actual path in the datastore does _not_ match up to these names listed. (I'm also not sure why govmomi is listing the same file twice, maybe the library item is screwed).

$ govc library.info -dump '/LolFuzz Templates/eval-win81x86-enterprise/'
[]interface {}{
    library.File{
        Cached:   types.NewBool(true),
        Checksum: &library.Checksum{Algorithm:"SHA1", Checksum:""},
        Name:     "eval-win81x86-enterprise.ovf",
        Size:     types.NewInt64(5642),
        Version:  "1",
    },
    library.File{
        Cached:   types.NewBool(true),
        Checksum: &library.Checksum{Algorithm:"SHA1", Checksum:""},
        Name:     "eval-win81x86-enterprise.ovf",
        Size:     types.NewInt64(5642),
        Version:  "1",
    },
}

Then if we export the ovf, the spec of the ovf template (according to the "type") is then contained within this xml. This is essentially what I'd like to properly get at through some means..

$ govc library.export '/LolFuzz Templates/eval-win81x86-enterprise/eval-win81x86-enterprise.ovf'
...
<?xml version='1.0' encoding='UTF-8'?>
<Envelope xmlns="http://schemas.dmtf.org/ovf/envelope/1" xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" xmlns:vmw="http://www.vmware.com/schema/ovf" xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData" xmlns:vssd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_VirtualSystemSettingData" vmw:buildId="build-4586971">
...

Actual question

So, is there some way for me to get to these attributes for the spec? Or at the very least can the "Type" attribute of the "vsphere_content_library_item" be exposed so that it can be switched on w/ some kind of conditional? Without some way to reference the files associated with the library item or its type, one is kind of left to assuming how to manage that particular resource.

I believe the reverse holds true as well in that without being able to specify the "Type" during creation, other consumers of the item won't be able to distinguish which "client" for the item should be used. I've encountered this problem before with other scripts as we used to store both "iso" and "ovf" types directly in a library, but decided upon splitting them up so that other things wouldn't break.

Potential Terraform Configuration

I dunno, maybe something like the following would be cool..

data "vsphere_content_library_item" "test-template" {
    name = "eval-win81x86-enterprise"
    library_id = data.vsphere_content_library.library.id
}

data "vsphere_ovf_specification" "test-template-specs" {
    item_id = data.vsphere_content_library_item.test-template.id
}

resource "vsphere_virtual_machine" "blah" {
    // maybe this
    memory = data.vsphere_ovf_specification.test-template-specs.memory

    // or this
    clone {
        template_uuid = data.vsphere_ovf_specification.test-template-specs.id
    }    
}

References

This is related to issue #1012, #291

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

(edited to change the priority of the headings)

[arizvisa]

This could be related to #1087, as I had the same issue which led me down this path only to realize that those IDs don't seem to correlate. This might also be related to #1098 as the log references an issue with the type being null.

[bill-rich]

Type added in #1184

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!