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

Allow duplicate nil pxe_image_types during seed (for the current region) #17544

Merged
merged 3 commits into from
Jun 13, 2018

Conversation

bdunne
Copy link
Member

@bdunne bdunne commented Jun 6, 2018

DEPENDS on #16775 for Gaprindashvili backport

@jrafanie @carbonin Please review

https://bugzilla.redhat.com/show_bug.cgi?id=1588417

We want to disallow the same name template in different regions with the
same pxe_image_type. Normally, region id sequences prevent this from
happening but we were treating nil pxe_image_types as the same.
Therefore you could have the "same" pxe_image_type in different regions
for the same name template.

@bdunne bdunne added the bug label Jun 6, 2018
@jrafanie
Copy link
Member

jrafanie commented Jun 7, 2018

@bdunne I wonder if we want to have a BZ for this one so we can backport this.

Copy link
Member

@jrafanie jrafanie left a comment

Choose a reason for hiding this comment

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

LGTM, maybe just add a BZ link

@carbonin
Copy link
Member

carbonin commented Jun 7, 2018

@jrafanie Should we wait and see if the BZ you're working on would be fixed by this change rather than opening a new one?

@jrafanie
Copy link
Member

jrafanie commented Jun 7, 2018

@jrafanie Should we wait and see if the BZ you're working on would be fixed by this change rather than opening a new one?

yeah, good point...let's hold off on merging until we have a possibility of recreating it

@jrafanie jrafanie changed the title Only seed stuff in the current region Allow non-unique nil pxe_image_types during seed (for the current region) Jun 7, 2018
@jrafanie
Copy link
Member

jrafanie commented Jun 7, 2018

@carbonin @bdunne @Fryguy Here's the changes @d-m-u and I did on top of Brandon's in_my_region change.

let(:customization_template) { FactoryGirl.create(:customization_template, :pxe_image_type => pxe_image_type) }
let(:system_customization_template) { described_class.create!(:system => true, :name => "nick") }

it "doesn't allow same name in same region" do
Copy link
Member

Choose a reason for hiding this comment

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

Is this true regardless of pxe image type? Should we also test for that?

Copy link
Member

Choose a reason for hiding this comment

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

Yes. Note, we had a test for that but it was merely an extension of this test so we removed it. The table @Fryguy wrote on the whiteboard had two customization templates with the same name in the same region could have any pxe image type. Maybe @bdunne @Fryguy know the use cases better to know if that still makes sense?

Copy link
Member

Choose a reason for hiding this comment

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

Wow, I wrote that completely wrong.

@Fryguy wrote on the whiteboard that two customization templates with the same name in the same region was OUT regardless of it's pxe image type. Right?

Copy link
Member

Choose a reason for hiding this comment

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

@d-m-u feel free to tell me I'm wrong or misremembering, I don't have the whiteboard in front of me.

Copy link
Member

Choose a reason for hiding this comment

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

@Fryguy wrote on the whiteboard that two customization templates with the same name in the same region was OUT regardless of it's pxe image type. Right?

Yeah, that's pretty much exactly what I was asking "Is this true regardless of pxe image type?" 😆


it "allow same name, nil pxe_image_types in different regions (for system seeding)" do
ctid = ApplicationRecord.id_in_region(system_customization_template.id, ApplicationRecord.my_region_number + 1)
expect { described_class.create!(:system => true, :name => "nick", :id => ctid) }.to change(described_class, :count).by(1)
Copy link
Member

Choose a reason for hiding this comment

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

I feel like using the to change() syntax here would allow this test to succeed even if the first template wasn't created. Can we be more explicit and assert that there are two templates with the same name directly?

Also the fact that the first creation is done in a (lazily evaluated) let makes it less clear that it is actually being created.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, that makes sense. We had this testing the two had the same name originally and I had the brilliant idea of changing it. @d-m-u was right but didn't stop me. 😉

pid = ApplicationRecord.id_in_region(pxe_image_type.id, MiqRegion.my_region_number + 1)
ctid = ApplicationRecord.id_in_region(customization_template.id, MiqRegion.my_region_number + 1)
pt2 = FactoryGirl.create(:pxe_image_type, :id => pid)
expect { FactoryGirl.create(:customization_template, :pxe_image_type => pt2, :id => ctid) }.to change(described_class, :count).by(1)
Copy link
Member

Choose a reason for hiding this comment

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

A name needs to be specified in this create call and in the let for customization_template. name is a sequence in the factory so the name of this record won't be the same as customization_template.name

Copy link
Member

Choose a reason for hiding this comment

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

Interesting, let me see if the test fails if I check that correctly. Good 👀

@jrafanie
Copy link
Member

jrafanie commented Jun 8, 2018

@carbonin @d-m-u I corrected the tests and hopefully made them easier to read at the expense of more lines added 😱

@jrafanie jrafanie changed the title Allow non-unique nil pxe_image_types during seed (for the current region) Allow duplicate nil pxe_image_types during seed (for the current region) Jun 8, 2018
Copy link
Member Author

@bdunne bdunne left a comment

Choose a reason for hiding this comment

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

Do we also need a test for "same name, same region, different pxe_image_type"?

@jrafanie
Copy link
Member

Do we also need a test for "same name, same region, different pxe_image_type"?

Sure, we already have it but it's not clear so I'll rename the test...

    it "doesn't allow same name in same region" do
      FactoryGirl.create(:customization_template, :name => "fred")
      expect { FactoryGirl.create(:customization_template, :name => "fred") }.to raise_error(ActiveRecord::RecordInvalid)
    end

expect { FactoryGirl.create(:customization_template, :name => "fred", :pxe_image_type => pit) }.to raise_error(ActiveRecord::RecordInvalid)
end

it "doesn't allow same name in same region with the different pxe_image_type" do
Copy link
Member Author

Choose a reason for hiding this comment

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

I think this should be allowed. cc @Fryguy to verify that

@jrafanie
Copy link
Member

bdunne
I think this should be allowed. cc @Fryguy to verify that

I have validated that @d-m-u knows her validations. We did lots of typos until we got it right but reversed the logic so now you can have the same name customization template with different pxe_image_types regardless of the region.


scope :with_pxe_image_type_id, ->(pxe_image_type_id) { where(:pxe_image_type_id => pxe_image_type_id) }
scope :with_system, ->(bool = true) { where(:system => bool) }

def not_seeding?
!system? || pxe_image_type.present?
Copy link
Member

Choose a reason for hiding this comment

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

Checking both system and presence is overkill since we have a pxe_image_type presence validation unless system? above... I guess it could just check !system


scope :with_pxe_image_type_id, ->(pxe_image_type_id) { where(:pxe_image_type_id => pxe_image_type_id) }
scope :with_system, ->(bool = true) { where(:system => bool) }

def not_seeding?
Copy link
Member

Choose a reason for hiding this comment

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

Can we make the method name not a negative? 😉

Copy link
Member

@jrafanie jrafanie Jun 12, 2018

Choose a reason for hiding this comment

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

Sure, give me a good name for it. :trollface:

I honestly have no idea why we're seeding customization templates with no pxe_image_type if pxe_image_type is required for validation of a customization template. This whole thing would be so much easier if seeding behaved properly. @bdunne do you know why seeding wants to be different?

Copy link
Member

Choose a reason for hiding this comment

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

Ignoring the validity of creating templates without a pxe_image_type for a second I'd be fine with just seeded_template?. I really just wanted to drop the not_ from the method.

Copy link
Member

Choose a reason for hiding this comment

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

yeah, there were reasons we went negative, but we tried many things so maybe @d-m-u's last magic try will allow us to use if instead of unless...I'll give it a go

Copy link
Member Author

Choose a reason for hiding this comment

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

@jrafanie The system images are not usable by customers. They're just there as examples that the user can copy. If you want, you can change seeding so that they get seeded into the system customization templates PxeImageType.

https://bugzilla.redhat.com/show_bug.cgi?id=1588417

We want to disallow the same name template in different regions with the
same pxe_image_type.  Normally, region id sequences prevent this from
happening but we were treating nil pxe_image_types as the same.
Therefore you could have the "same" pxe_image_type in different regions
for the same name template.
@jrafanie
Copy link
Member

I have no idea... @d-m-u was there and we could only get it to work with if and a negative condition. I was able to mostly reverse the logic and the tests still pass. 🤷‍♂️ I blame the fresh air and pollen during our hike.

@carbonin
Copy link
Member

Strange, looks like the unique_within_region validator spec failed because we were relying on it being used in this model (which has been removed).

@jrafanie
Copy link
Member

Strange, looks like the unique_within_region validator spec failed because we were relying on it being used in this model (which has been removed).

Yeah, I was hoping I can just delete it but the test is trying to test STI with two subclass instances with the same template name. I will have to see if I can test that in a class agnostic way.

Since CustomizationTemplate no longer uses the unique within region
validation, change the test to use anonymous STI classes hardcoded to
use the vms table.
@jrafanie
Copy link
Member

@carbonin I changed the unique within region spec to use anonymous classes instead of CustomizationTemplate since the latter no longer uses unique within region.

@miq-bot
Copy link
Member

miq-bot commented Jun 12, 2018

Checked commits bdunne/manageiq@63f07d5~...4644f3e with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0
3 files checked, 0 offenses detected
Everything looks fine. 🏆

Copy link
Member

@carbonin carbonin left a comment

Choose a reason for hiding this comment

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

Spec failures look unrelated.

@jrafanie
Copy link
Member

Yeah, I think #17562 broke master but have no idea why

@carbonin
Copy link
Member

ManageIQ/manageiq-providers-ansible_tower#81 was the issue @jrafanie a fix has been merged so I restarted the tests.

Copy link
Member Author

@bdunne bdunne left a comment

Choose a reason for hiding this comment

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

👍 LGTM

@gtanzillo gtanzillo self-assigned this Jun 13, 2018
@gtanzillo gtanzillo added this to the Sprint 88 Ending Jun 18, 2018 milestone Jun 13, 2018
@gtanzillo gtanzillo merged commit e8b923a into ManageIQ:master Jun 13, 2018
@bdunne bdunne deleted the scope_seeding branch June 13, 2018 14:47
@jrafanie
Copy link
Member

ManageIQ/manageiq-providers-ansible_tower#81 was the issue @jrafanie a fix has been merged so I restarted the tests.

😅 🙇 🥇

@jrafanie
Copy link
Member

I believe this won't backport directly so I'll open a PR for gaprindashvili

@jrafanie
Copy link
Member

jrafanie commented Jun 13, 2018

Ah, the gaprindashvili cherry-pick is clean (and tests pass!) if we backport the dependent PR from @d-m-u first.

git cherry-pick -x -m1 c992bac
git cherry-pick -x -m1 e8b923a

Updating this PR and the other one.

simaishi pushed a commit that referenced this pull request Jun 14, 2018
Allow duplicate nil pxe_image_types during seed (for the current region)
(cherry picked from commit e8b923a)

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1591450
@simaishi
Copy link
Contributor

Gaprindashvili backport details:

$ git log -1
commit 9deace37264d31721f58a22f464e1a757571807c
Author: Gregg Tanzillo <gtanzill@redhat.com>
Date:   Wed Jun 13 10:35:48 2018 -0400

    Merge pull request #17544 from bdunne/scope_seeding
    
    Allow duplicate nil pxe_image_types during seed (for the current region)
    (cherry picked from commit e8b923a569b443ed250ed47f86e60bccd78b17af)
    
    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1591450

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.

6 participants