-
Notifications
You must be signed in to change notification settings - Fork 290
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
fixes #7890 Move Distributions from Elasticsearch to the Database #5362
Conversation
before testing: rake db:migrate && rake katello:upgrades:2.4:import_distributions |
@@ -1,38 +0,0 @@ | |||
module Katello | |||
class Api::V2::DistributionsController < Api::V2::ApiController |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are removing this, we need to also remove the routes related to it, further, we need to ask ourselves if this is breaking our API contract and if we need to rev our versioning in light of.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be a better idea to leave it in so the API functions as it did before? and that would mean leaving in the Distribution model and Glue::ElasticSearch::Distribution as well, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're completely getting rid of an object, I'm fairly okay with this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I follow exactly, you are saying because we are removing an object from conceptual existence, you are OK treating this API removal as not a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty much. I'm sure others would disagree, but really this api doesn't even make sense. the index call requires a repository_id and returns a list, even though there will ever be one.
We could maintain this api (minus the searching) with these attributes: :version, :arch, :family, :variant simply by mapping the repo object i guess. That would be fairly simple. Maintaining the full api (minus search syntax compatibility, which i guess we've determined is okay to change) would basically dictate how the model is done (and not done the way we discussed).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose we could throw a deprecation warning into 2.3?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like a plan!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just so I understand, @jlsherrill when you say mapping the repo object, do you mean adding the distribution attributes to the repository api (which is done here) or making a child object "distribution" of the repo object when showing a repository in the api?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was suggesting we could maintain the existing controller, but instead of rendering distribution objects, we render repo objects with the distribution attributes. But eric is now suggesting we just deprecate the distribution api in the 2.3 release (which is not out yet), and get rid of it in this PR
[test] |
@@ -15,6 +15,11 @@ attributes :gpg_key_id | |||
attributes :content_id, :content_view_version_id, :library_instance_id | |||
attributes :product_type | |||
attributes :promoted? => :promoted | |||
attributes :distribution_version | |||
attributes :distribution_arch | |||
attributes :distribution_bootable? => :distribution_bootable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what started my question around this function, as it seems like you should just rely on the database attribute instead of mapping a function to this attribute?
169a44b
to
e430466
Compare
e430466
to
9b98ff8
Compare
9b98ff8
to
6db574a
Compare
f09c907
to
00b11b0
Compare
0ffbf8b
to
b7c6286
Compare
[test] |
651dba4
to
9ce87dc
Compare
@johnpmitsch looks like you need a rebase here |
9ce87dc
to
769c87e
Compare
@ehelms Thanks, just rebased |
conflicts.select { |conflict| conflict[:distributions].length > 1 } | ||
repos = self.repositories_to_publish.where("distribution_arch IS NOT NULL OR distribution_version IS NOT NULL") | ||
repos.group_by { |repo| [repo.distribution_arch, repo.distribution_version] } | ||
.select { |_, value| value.length > 1 }.values.flatten |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should only include bootable distros right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(it doesn't look like it does)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ya it was including all distros, I just changed it, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe i'm misreading this, but i don't see where that was changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whoops
769c87e
to
b4825e9
Compare
b4825e9
to
e1e6292
Compare
conflicts.select { |conflict| conflict[:distributions].length > 1 } | ||
repos = self.repositories_to_publish.where("distribution_arch IS NOT NULL OR distribution_version IS NOT NULL") | ||
repos = repos.select { |repo| repo.distribution_bootable? } | ||
repos.group_by { |repo| [repo.distribution_arch, repo.distribution_version] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jlsherrill ok that should do it
ACK from me, ehelms? |
👍 |
Merging, thanks @johnpmitsch |
fixes #7890 Move Distributions from Elasticsearch to the Database
Adds distribution values from pulp as attributes to Repository. They are added to the UI and users are now able to search on these values using scoped search