Improve support for content library

[stobias123]

Description

Content Library Support is severely lacking. Capabilities available here -> https://github.com/vmware/govmomi/blob/master/govc/USAGE.md#librarycreate

Should also be available to this provider.

Potential Terraform Configuration

resource "vsphere_content_library" "library" {
  name            = "Content Library Test"
  storage_backing = data.vsphere_datastore.datastore.id
  description     = "A new source of content"
  publish = false
  subscription = "blah"
  sync_settings {
    period = 1d
  }
}

References

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

[bill-rich]

Hi @stobias123! Many of those capabilities were added to govmomi after Content Library was implemented in the Terraform provider. I would very much like to add those features though. I've added it to the backlog.

[arizvisa]

Specifically with regards to library items..

The library.deploy command of govc, is implemented primarily by the command and not within the govmomi library that is used by terraform-provider-vsphere. So, there isn't really an elegant way to use these particular capabilities unless we want to call library.deploy.Run explicitly, and not really have access to any other attributes other than what can be parsed from stdout(?).

This is due to the client types not being wrapped in any sorta way which results in the content library literally just being a "file server" from our perspective. The session API for example, is for locking a library item in order to upload/download its files. Subscriptions are what you'd expect them to be, which leaves only content library items and their contents.

In order to use a library item's contents with the current state of what govmomi exposes to us, we'd need to look at the "Type" field for the library item, and then an implementor would need to manually develop individual clients for the "iso", "ovf", and "vm-template" library item types. This'd be essentially a minor project as these "clients" will need to know what each library item type will contain, and how to extract attributes from all 3 (currently existing) types.

I noted this in a longwinded issue #1126 where I was trying to figure out how to use hcl in order to extract some attributes from a content library item where my type was "ovf".

[melck]

Any news on content library deployment ? I saw that issues linked have been closed or resolved.

[arizvisa]

@melck, do you mean creating a content library and publishing items into it, or do you mean referencing files (items that have been published into a content library) when cloning a machine/template?

[tenthirtyam]

@stobias123, which content library features do you feel are most need by the provider?

Ryan

[arizvisa]

As per #1126, the "type" attribute was added thanks to #1184. With this, you can at least use conditionals to choose the right resource and combine it with some local script via the "external" provider to download the content and export them as a "data source" with json.

However, instead...it would be super SUPER freaking awesome to have clients for all 3 of the client types listed in #1558.

The thing that's kind of a shame, though, is that although govmomi exposes this attribute to its users, it's expected that an implementor implements the client for the correct "type" themselves. The content library is literally just a pub/sub datastore that doesn't expose any sort of api constraining how you access the files that it serves.

So the content library api only allows you subscribe to changes, publish changes, and upload or download said content. Thus in order to implement the clients for these types in a provider, one would have to write a "data source" and "resource" that downloads the necessary files and processes them differently depending on whether it's a "vm-template" type, the "ovf" type, or the "iso" type.

• The "iso" type is easy, because it's just a simple file transfer. You can expose it as a url.
• The "vm-template" type, however, will require parsing and generating a .vmx file (in order to provide a "data source" and a "resource" respectively).
• The "ovf" content types, however, will require parsing the manifest and descriptor files so that they can also be exposed as a "data source" or generated as a "resource".

Maybe there's a golang module for parsing the manifests that expose these necessary attributes, but the generation of these manifests seems less likely. At the very least, one could allow the user to generate one using "templatefile" (and something similar for xml) and then the content library "resource" for each of the types could just upload it into the content library, exposing the url and UUID.

[stobias123]

@tenthirtyam almost 2 years since this was opened. I'm not the right person to ask anymore 😅 . No longer using vmware.