Skip to content
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

Collect customization_specs #614

Merged
merged 2 commits into from
Sep 17, 2020

Conversation

agrare
Copy link
Member

@agrare agrare commented Aug 18, 2020

The collection of customization_specs with streaming refresh was missed when moving from legacy refresh because there weren't any in the VCRs for the spec tests

TODO:

  • Record updated VCR cassettes
  • Update provisioning to convert Hash to VimHash CustomizationSpecInfo type

Follow-up:

Fixes #611

@agrare agrare requested a review from Fryguy as a code owner August 18, 2020 19:06
@agrare agrare changed the title Collect customization_specs [WIP] Collect customization_specs Aug 18, 2020
@agrare agrare force-pushed the collect_customization_specs branch 2 times, most recently from 5e23239 to 8297e5e Compare August 18, 2020 19:10
@@ -377,4 +391,16 @@ def lazy_find_managed_object(managed_object)
parent_collection = persister.vim_class_to_collection(managed_object)
parent_collection.lazy_find(managed_object._ref)
end

def rbvmomi_to_basic_types(obj)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally we could just do obj.to_h and the RbVmomi classes would support this, going to work on an rbvmomi PR to add this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My change for this actually got merged but hasn't been released yet, I'll update this when a release is cut

@agrare agrare force-pushed the collect_customization_specs branch 6 times, most recently from ffacb3e to 1ecbe28 Compare August 20, 2020 13:49
return cs

source.with_provider_connection do |vim|
vim.getVimCustomizationSpecManager.getCustomizationSpec(cs.name)&.spec
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CustomizationSpec has a number of properties where the VIM class matters (e.g.: CustomizationLinuxOptions vs CustomizationWinOptions) so we can't just use the standard hash stored in the DB

Previously this was a serialized VimHash which included the class names (we'll need a migration to clean these up, didn't realize that CustomizationSpec#spec was the full vim object)

Fetching the spec from the vcenter seemed to be the best option, other option is to add the VIM class name as a hash key when we convert from the native object to a hash in the parser as something like a :_xsiType key but the user would be able to modify those in the provision dialog unless we strip them out.

I'm open to other ideas though

@agrare agrare changed the title [WIP] Collect customization_specs Collect customization_specs Aug 20, 2020
@miq-bot miq-bot removed the wip label Aug 20, 2020
@Fryguy
Copy link
Member

Fryguy commented Aug 21, 2020

@agrare Do you think we can get this in in time for jansa-1 release? I'd rather not have this regression in the release if we can avoid it.

cc @chessbyte @gtanzillo

def retrieve_customization_spec(spec_manager, cached_props)
cached_props[:info].to_a.each do |spec_info|
spec_info.props[:spec] = spec_manager.GetCustomizationSpec(:name => spec_info.name)&.spec
rescue RbVmomi::Fault => err
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the failure occur in the middle of the loop, does this move on or end the loop?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also ewww N+1...There's no way to bulk ask this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would move on to the next one not skip, and no unfortunately not you can't get multiple customization scripts at once.

Copy link
Member Author

@agrare agrare Aug 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was done here previously, the other option is to get the full spec at provision time which is closer to what the vsphere client does

@agrare agrare force-pushed the collect_customization_specs branch 3 times, most recently from 94f71d8 to 8f061a8 Compare August 26, 2020 22:43
The collection of customization_spces with streaming refresh was missed
when moving from legacy refresh
@agrare agrare force-pushed the collect_customization_specs branch 2 times, most recently from 59f660c to 2487628 Compare September 10, 2020 14:41
@agrare agrare force-pushed the collect_customization_specs branch from 2487628 to f6ecfb0 Compare September 10, 2020 14:41
@miq-bot
Copy link
Member

miq-bot commented Sep 10, 2020

Checked commits agrare/manageiq-providers-vmware@16d3f94~...f6ecfb0 with ruby 2.6.3, rubocop 0.69.0, haml-lint 0.28.0, and yamllint
5 files checked, 0 offenses detected
Everything looks fine. 🏆

@agrare agrare requested a review from gtanzillo September 10, 2020 14:56
@simaishi
Copy link
Contributor

@agrare backport conflicts on vcr cassettes as #591 is not in jansa branch. Not sure if you need to re-record for jansa?

@agrare
Copy link
Member Author

agrare commented Sep 28, 2020

If possible I'd like to keep the VCRs the same otherwise every PR we backport will conflict (aka OpenStack provider). I'll mark #591 as jansa/yes?

simaishi pushed a commit that referenced this pull request Oct 1, 2020
Collect customization_specs

(cherry picked from commit 333b9d0)
@simaishi
Copy link
Contributor

simaishi commented Oct 1, 2020

Jansa backport details:

$ git log -1
commit d4bda6fedda4c7ca62401bc02c2cdac0a6177b61
Author: Jason Frey <[email protected]>
Date:   Thu Sep 17 14:30:30 2020 -0400

    Merge pull request #614 from agrare/collect_customization_specs

    Collect customization_specs

    (cherry picked from commit 333b9d004e7e170398021631f7c9a1dc79a63a32)

Copy link

@Nikkurer Nikkurer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that there is a typo. Please check.

props[:info].to_a.each do |spec_info|
persister.customization_specs.build(
:name => spec_info[:name],
:typ => spec_info[:type],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be :type

Copy link
Member Author

@agrare agrare Oct 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:type is a reserved column name used by STI, :typ is correct here used to not conflict with STI.

Here is the database table definition: https://github.com/ManageIQ/manageiq-schema/blob/master/db/migrate/20130923182042_collapsed_initial_migration.rb#L303

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

VMware customization specifications not detected in Jansa
6 participants