-
Notifications
You must be signed in to change notification settings - Fork 104
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
Problems with pivnet packaging and build-numbers #408
Comments
We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story. The labels on this github issue will be updated when the story is started. |
Thank you for sharing! I've also shared with the PivNet team and we will discuss further. |
@aegershman while there is definite room for improvement this is where the om tile-metadata command can help in the current spaces.
This prevents you from having to first upload it or manually parse the tile metadata. |
Is there a reason that the |
@rszumlakowski I believe it is up to the tile teams themselves to decide how their product appears on pivnet. |
@aegershman @calebwashburn @rszumlakowski Extend Thoughts? |
@iplay88keys The solution you are suggesting involves making changes to PIVNET and the way the authors generate metadata, which is outside of the scope for this specific tool, if no further discussions we are going to close this. |
@jaristiz It's been a long time since I was on the Platform Automation team and we were managing From what I recall, Currently,
Our suggestion was extend The the resulting command could look like this, then:
|
Thanks for your reply. I'll put this on our backlog so we can take a look and decide how much effort would be needed to make this a reality. For now, I am going to tag this one as enhancement and keep it alive. |
I like this idea, but I'm cautious about using the presence/absence of Pivnet configuration as the implicit switch, as I believe it can also be loaded from env vars. I'd prefer it with an explicit flag. This has a couple of small usability implications:
I suspect this may complicate the validation quite a bit. Offering an alternative, I'd take an alternate version of the command, which might make for simpler validation logic. Either way's fine, just wanting to offer up easier paths if input validation gets dicey. Nice to see you, @iplay88keys. |
@anEXPer Great points! I think that offers a better user experience. I'll work on the explicit flag option first and see how that turns out. Nice to see you too! |
I submitted the PR. At this point, however, it is not accepting Environment variables directly for configuration options as it wasn't accepting them before this change, though it still works with a config file being interpolated by env vars:
As such, it works like |
Nice addition! Merged. Also, good to see you again @iplay88keys ! |
Thanks! Good to see you as well! |
Hello from the future 👋 hope all is well. closing to prune open issues. take care all 🫡 |
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 as2.1.3
, it's using a-build.xyz
number, referenced as2.1.3-build.34
.Therefore,
om
cannot reference it using the product version it used previously in 2.1.2, which would beom stage-product --product-name p-redis --product-version 2.1.2
(the working command for
2.1.3
would beom 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 aboutpivotal-mysql 2.6.2-build.10
. So for pivotal-mysql, even though the product version according to pivnet is2.6.2
, you can extract2.6.2-build.10
from the file name, because2.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 as2.1.3
or2.2.0
, even though the "real" product version is2.1.3-build.34
or2.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...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 otherom
tasks use can reference it.Interested in thoughts people have on this, but feel free to close whenever.
Thanks!
The text was updated successfully, but these errors were encountered: