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

support find and lazy_find by other fields than manager_ref #15447

Merged
merged 1 commit into from Jul 4, 2017

Conversation

cben
Copy link
Contributor

@cben cben commented Jun 26, 2017

Rationale:
Kubernetes API gives us permanently unique "UID"s, but expresses links to other objects via "name"s that are only only momentarily unique.
[https://kubernetes.io/docs/concepts/overview/working-with-objects/names/]

We want to keep using the UIDs are ems_ref and graph refresh's manager_ref.
But we need ability to lazy_find by name.
This PR is POC for extending InventoryCollection with extra indexes as suggested in
ManageIQ/manageiq-providers-kubernetes#30 (comment)

  • incomplete, just the parts I needed
  • missing tests & docs
  • naming is bad...

@Ladas @agrare Would you have time to flesh this out?

Ideas that might make it friendlier:

  • embed which index inside the foo__bar strings, so once constructed you don't need to pass around which index you're referring to ?
    then we can mix all indexes in one hash (this may be a decision that's hard reverse?).
  • autodetect index from keys passed to find_by / lazy_find_by ?

@miq-bot miq-bot added the wip label Jun 26, 2017
@miq-bot
Copy link
Member

miq-bot commented Jun 26, 2017

Checked commit cben@c666ac2 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
3 files checked, 5 offenses detected

app/models/manager_refresh/inventory_collection.rb

@agrare
Copy link
Member

agrare commented Jun 27, 2017

@cben I like this a lot, I wonder if :manager_ref can just become a special case default of a more general index.

@agrare agrare self-assigned this Jun 28, 2017
@cben
Copy link
Contributor Author

cben commented Jul 3, 2017

Did you by chance make any progress on this / have advice how I should move this forward?

I want to either land something like this soon, or unblock ManageIQ/manageiq-providers-kubernetes#52 by temporarily using data_index...

@@ -341,9 +342,10 @@ def initialize(model_class: nil, manager_ref: nil, association: nil, parent: nil
check_changed: nil, custom_manager_uuid: nil, custom_db_finder: nil, arel: nil, builder_params: {},
inventory_object_attributes: nil, unique_index_columns: nil, name: nil, saver_strategy: nil,
parent_inventory_collections: nil, manager_uuids: [], all_manager_uuids: nil, targeted_arel: nil,
targeted: nil, manager_ref_allowed_nil: nil)
targeted: nil, manager_ref_allowed_nil: nil, secondary_refs: {})
Copy link
Contributor

Choose a reason for hiding this comment

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

@agrare any naming idea? Also would be nice to get the interface right, so it's easier to do to refactoring of the inside.

@agrare @cben
maybe if can be just indexes?

:indexes => {
  :name_label_index => {
    :attributes => [:name, :label],
    :unique => true
  },
   :other_index => {
    :attributes => [:other],
    :unique => false
  },
}

or maybe we should wrap index as an object right away?

:indexes => [
  InventoryCollection::Index.new([:name, :label], :unique => true),
  InventoryCollection::Index.new([:other], :unique => false, :name => "other_index"
]

(we could also extract the @data_index into InventoryCollection::Data)

and we might not need to name the indexes at all I guess, we can just check if the combination of attributes is there as an index, even with O(c) if we use the attribute list as an index?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah I think putting these into one :index or :indexes makes sense, if we are going to pass in names of indexes I think :additional_indexes would be better than :secondary_refs

As for extracting @data_index I think that it would be better to keep it private

@Ladas
Copy link
Contributor

Ladas commented Jul 3, 2017

@cben

then we can mix all indexes in one hash (this may be a decision that's hard reverse?).

Right I am thinking that foo__bar can be changed to hash, or object really. The string encoding was there to spare some memory when having millions of records in 1 big hash. Since we go into stream saving, we can bloat the indexes a bit.

autodetect index from keys passed to find_by / lazy_find_by ?

yeah, should be enough to find by some combination of attributes and pick the index according to that, or raise exception that such index is missing


Would be nice if we can get the interface right, to avoid replacing it on many places later. But maybe we will anyway. :-)

Looks like this is all we need for the full refresh. We will need to extend the DB loading, for the partial/stream refresh.

@agrare
Copy link
Member

agrare commented Jul 3, 2017

@cben can you check if the Amazon and ansible tower refresher specs pass with these changes? If so I'll merge this and we can make the interface better in a follow-up.

@cben
Copy link
Contributor Author

cben commented Jul 4, 2017

ansible_tower and amazon tests pass (but 39 skipped "AWS S3 is disabled").

I'm slightly embarassed to have this merged as-is, but will not at all object :-)

@Ladas
Copy link
Contributor

Ladas commented Jul 4, 2017

@agrare ok, tests are passing, it's ok to merge. We or I will refactor it later. :-)

@cben just remove the WIP label :-)

@cben cben changed the title [WIP] support find and lazy_find by other fields than manager_ref support find and lazy_find by other fields than manager_ref Jul 4, 2017
@miq-bot miq-bot removed the wip label Jul 4, 2017
@agrare agrare merged commit ab0383c into ManageIQ:master Jul 4, 2017
@agrare agrare added this to the Sprint 64 Ending Jul 10, 2017 milestone Jul 4, 2017
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.

None yet

4 participants