om: Problems with pivnet packaging and build-numbers

Forgive me for these write-ups, but it’s very useful to externalize them in pivotal-cf/om and make them visible for future references.

Starting in p-redis 2.1.3, the product version in opsmgr is no longer referenced as 2.1.3, it’s using a -build.xyz number, referenced as 2.1.3-build.34.

Therefore, om cannot reference it using the product version it used previously in 2.1.2, which would be om stage-product --product-name p-redis --product-version 2.1.2

(the working command for 2.1.3 would be om stage-product --product-name p-redis --product-version 2.1.3-build.34)

Using the -build.xyz suffix isn’t a problem, though. The problem is when the build suffix isn’t available upfront as part of the product’s distribution from pivnet, and only visible once it’s been uploaded into opsmgr.

Notice in the case of pivotal-mysql, which uses build suffixes, the build suffix is available as part of the actual file name included in the pivnet bundle:

This allows automation to pull the build suffix pattern off the file so that tasks doing commands like om stage-product, configure-product, apply-changes, etc. can reference the “real” product version when it talks to opsmgr about pivotal-mysql 2.6.2-build.10. So for pivotal-mysql, even though the product version according to pivnet is 2.6.2, you can extract 2.6.2-build.10 from the file name, because 2.6.2-build.10 isn’t included anywhere else like in the pivnet metadata, etc.

THEREFORE, in situations like p-redis, where the product version is listed as 2.1.3 or 2.2.0, even though the “real” product version is 2.1.3-build.34 or 2.2.0-build.90, since the product’s file doesn’t include the build suffix, there’s no reasonable way to extract the actual product version:

The only way to get this data would be to either upload the product into an opsmgr, query for available-products, and then do regex parsing to get the build suffix…

# om --env ./env-pez19.yml available-products
+----------------------+----------------+
|         NAME         |    VERSION     |
+----------------------+----------------+
| p-redis              | 2.1.2          |
| cf                   | 2.4.11         |
| p-rabbitmq           | 1.16.3         |
| apmPostgres          | 1.6.1-build.12 |
| p-push-notifications | 1.10.3-build.1 |
| cf                   | 2.4.3          |
| p-redis              | 2.1.3-build.34 |
| pivotal-mysql        | 2.5.4-build.51 |
+----------------------+----------------+

OR doing something kind of funky by cracking open the p-redis-2.1.3.pivotal and doing a bunch of parsing logic to get to wherever in the *.pivotal bundle the “real” product version is stored, and then saving that off.

All in all, it’s easier if the product version is stored in the product bundle’s filename so it can be parsed out during the initial download from pivnet; or some variation where the product-version which other om tasks use can reference it.

Interested in thoughts people have on this, but feel free to close whenever.

Thanks!