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

Container Template: Add object_labels #15406

Merged
merged 1 commit into from
Sep 6, 2017

Conversation

zakiva
Copy link
Contributor

@zakiva zakiva commented Jun 20, 2017

Depends on: ManageIQ/manageiq-schema#32

Changes included:

@zakiva
Copy link
Contributor Author

zakiva commented Jun 20, 2017

@miq-bot add_label providers/containers, enhancement

@zakiva
Copy link
Contributor Author

zakiva commented Jun 20, 2017

@lfu This will allow sending the instantiate method the template.object_labels (hash) merged with additional key-value pairs as you'll need. Please review.
cc @simon3z

@simon3z
Copy link
Contributor

simon3z commented Jun 20, 2017

@zakiva aren't labels a one-to-many relationship to custom_attributes for other entities? Why to implement it differently here?

@zakiva
Copy link
Contributor Author

zakiva commented Jun 21, 2017

@zakiva aren't labels a one-to-many relationship to custom_attributes for other entities? Why to implement it differently here?

Template also has one-to-many relationship to custom_attributes for its labels.
The object_labels added here are quite different, we save them in the DB in order to use them when instantiating the template (same as we do for template.objects).
I can still implement them as custom_attributes just with a different section but this means that we'll need to:

  1. Parse the labels (hash) from the inventory and save them as custom_attributes when refreshing.
  2. Parse the custom_attributes from the DB and convert back into hash before sending to Openshift when instantiating the template.

@simon3z
Copy link
Contributor

simon3z commented Jun 21, 2017

@zakiva then these labels seems instantiation-time labels that we shouldn't persist in the database.

@miq-bot
Copy link
Member

miq-bot commented Jun 22, 2017

This pull request is not mergeable. Please rebase and repush.

@Fryguy
Copy link
Member

Fryguy commented Jun 22, 2017

Database migrations have now been moved to the https://github.com/ManageIQ/manageiq-schema repo. Please see http://talk.manageiq.org/t/new-split-repo-manageiq-schema/2478 for instructions on how to transfer your database migrations. If this PR contains only migrations, I will leave it open for a short time during the transition, after which I will close this if it has not been moved over.

@lfu
Copy link
Member

lfu commented Jun 22, 2017

@zakiva Maybe these user specified labels should be saved the same way as the user specified parameters? These parameters currently are saved in Service/ServiceTemplate.

@simon3z
Copy link
Contributor

simon3z commented Jul 4, 2017

@zakiva @lfu let me know if you need to move this forward (btw it now requires the migration to be moved to the manageiq-schema repo).
I am available for reviews/suggestions, etc.

@zakiva
Copy link
Contributor Author

zakiva commented Jul 5, 2017

it now requires the migration to be moved to the manageiq-schema repo

@simon3z done, please take a look

@@ -26,15 +27,16 @@ class ContainerTemplate < ApplicationRecord
"Service" => ContainerService,
}.freeze

def instantiate(params, project = nil)
def instantiate(params, labels, project = nil)
Copy link
Member

Choose a reason for hiding this comment

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

@zakiva Is it better to make labels an optional parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we can use template.object_labels as default value, if you prefer? (I thought that we always want to add a unique template label to mark the objects)

Copy link
Member

Choose a reason for hiding this comment

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

I don't mind leave it the same as for template parameters for now.

@lfu
Copy link
Member

lfu commented Jul 5, 2017

@zakiva If I understand it correctly, the user input instantiation-time labels will be saved in service if implemented later, and those specified in the template will be saved as object_labels in container_templates in DB.
What is the purpose for the labels saved as custom_attributes for container_templates? Are they still needed?

@zakiva
Copy link
Contributor Author

zakiva commented Jul 5, 2017

What is the purpose for the labels saved as custom_attributes for container_templates? Are they still needed?

Those are labels that we save for the template as part of its metadata, as we do for the rest of the container objects.

The new object_labels added here are different. We use them so each created object will be tagged with these labels during instantiation (the labels will then be saved as custom_attributes of the related object).

Copy link
Member

@lfu lfu left a comment

Choose a reason for hiding this comment

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

Can we add some tests?

@zakiva
Copy link
Contributor Author

zakiva commented Jul 18, 2017

Can we add some tests?

@lfu added in ManageIQ/manageiq-providers-openshift#37

@zakiva
Copy link
Contributor Author

zakiva commented Jul 18, 2017

@miq-bot rm_label sql migration

@miq-bot
Copy link
Member

miq-bot commented Aug 2, 2017

This pull request is not mergeable. Please rebase and repush.

@miq-bot
Copy link
Member

miq-bot commented Aug 21, 2017

Checked commit zakiva@c00ba9e with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0
1 file checked, 0 offenses detected
Everything looks fine. 🏆

@cben
Copy link
Contributor

cben commented Sep 3, 2017

LGTM.

Using custom_attributes (with new section) could make sense for consistency, but for this use case both are fine. We don't need to search by them.
Refresh performance wise, a serialized column should be OK, possibly better than custom_attributes (untested). With normal amounts of templates, I don't expect it will be significant either way.

(A 3rd option would be a JSONB column; I don't know enough about that to say anything.)

@simon3z
Copy link
Contributor

simon3z commented Sep 4, 2017

@cben this is still waiting a technical review of the dependency ManageIQ/manageiq-schema#32

@simon3z
Copy link
Contributor

simon3z commented Sep 4, 2017

👍
@miq-bot assign blomquisg

@simon3z
Copy link
Contributor

simon3z commented Sep 4, 2017

@cben can you approve?

@miq-bot miq-bot assigned blomquisg and unassigned simon3z Sep 4, 2017
@Fryguy Fryguy merged commit c44efe3 into ManageIQ:master Sep 6, 2017
@Fryguy Fryguy added this to the Sprint 69 Ending Sep 18, 2017 milestone Sep 6, 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.

8 participants