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

Fix the condition for upstream members #1276

Merged

Conversation

SaschaDoering
Copy link
Contributor

Pull Request (PR) description

The condition which decides if we have upstream members configurred or
if we import from PuppetDB was wrong. Even if no upstream members are
defined the condition was true. As a result, you couldn't import upstream
members no matter what you configured. Sorry for that

This Pull Request (PR) fixes the following issues

Fixes GH-1274

@ghost ghost force-pushed the 1274_fix_upstream_member_condition branch 3 times, most recently from 7ff7f7e to 30bd2a7 Compare November 13, 2018 15:40
@SaschaDoering SaschaDoering force-pushed the 1274_fix_upstream_member_condition branch 2 times, most recently from 03d4c8e to 0599bf7 Compare November 19, 2018 12:59
@SaschaDoering
Copy link
Contributor Author

Hi,

there seem to be problems installing Nginx, which is why some tests fail. I don't know how this should be related to the change I made. Also the master branch failed too, so I think this is another issue. So in my opinion, this problem is fixed. Or have I overlooked something here?

@ekohl
Copy link
Member

ekohl commented Nov 19, 2018

I think it'd be better if we made members an Optional[...] and default to undef. That way you have explicit control over if you want to specify members or use a collector. An alternative is an additional parameter to specify the behavior but that feels redundant.

@SaschaDoering
Copy link
Contributor Author

First, thanks for your reply. I think both solutions are valid. In both cases, I have the decision whether to define or collect the upstream members. You choose to collect in which you don't define a member, but I think that's independent of the datatype we're using. In this respect, I don't see any logical difference between the two solutions, or did I get something wrong?

@ekohl
Copy link
Member

ekohl commented Nov 19, 2018

No, you got it right: essentially there must be a choice for the module user between members and collection. Currently you can't.

I think that changing the parameter to Optional[Nginx::UpstreamMembers] $members = undef, restores the behavior from before f0bf83a.

Could you also add a test that ensures this is possible so we don't accidentally break this again? Currently the tests are broken on a new GPG key on the passenger repository though.

@SaschaDoering
Copy link
Contributor Author

The first version of the commit f0bf83a contained a hash with undef as default. This was changed in cause of this comment #1233 (comment).
In addition, this contradicts the documentary on https://voxpupuli.org/docs/:

Are there new params with datatype Hash or Array? If possible, they should default to empty Hash/Array instead of undef. You can also enforce the datastructure like Array[String].

But I agree, there should be a test for that. I'll try to create one

@ekohl
Copy link
Member

ekohl commented Nov 19, 2018

Note the If possible, but here additional functionality is overloaded in it. (cc @bastelfreak)

@Dan33l
Copy link
Member

Dan33l commented Nov 19, 2018

I tested locally master branch with centos7. And i was able to reproduce failing run at same step with same messages :

  Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install passenger' returned 1: Importing GPG key 0xD59097AB:
   Userid     : "packagecloud ops (production key) <ops@packagecloud.io>"
   Fingerprint: 418a 7f2f b0e1 e6e7 eabf 6fe8 c2e7 3424 d590 97ab
   From       : https://packagecloud.io/gpg.key
  
  
   One of the configured repositories failed (passenger repo),
   and yum doesn't have enough cached data to continue. At this point the only
   safe thing yum can do is fail.

@ekohl
Copy link
Member

ekohl commented Nov 19, 2018

I think we'll need the equivalent of puppetlabs/puppetlabs-apache#1848

@SaschaDoering
Copy link
Contributor Author

Unfortunately, I didn't get to create a test for it. Because I would have to import exported resources, which, according to my information booth, is not possible. Or does anyone know a way to implement that?

The condition which decides if we have upstream members configurred or
if we import from PuppetDB was wrong. Even if no upstream members are
defined the condition was true.

Fixes voxpupuliGH-1274
@SaschaDoering SaschaDoering force-pushed the 1274_fix_upstream_member_condition branch from 0599bf7 to 5f9f9e4 Compare November 28, 2018 13:46
@SaschaDoering
Copy link
Contributor Author

So, all tests are OK again. If nobody knows a way to implement a test with imported resources from somewhere I think I'm finished here.

Copy link
Member

@ekohl ekohl left a comment

Choose a reason for hiding this comment

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

https://github.com/rodjek/rspec-puppet#testing-exported-resources does mention testing exported resources, but I don't see a way to collect them. A somewhat ugly workaround for this would be creating a define:

define nginx::resource::upstream::collector (
  Optional[String] $members_tag = undef,
) {
  if $members_tag {
    Nginx::Resource::Upstream::Member <<| upstream == $name and tag == $members_tag |>>
  } else {
    Nginx::Resource::Upstream::Member <<| upstream == $name |>>
  }
}

Then in this class you do:

nginx::resource::usptream::collector { $name:
  members_tag => $members_tag,
}

This would allow you to test for it:

it { is_expected.to contain_nginx__resource__upstream__collector(name).with_members_tag(nil) }

Not sure that's worth it so I'm fine with merging without tests as well.

@Dan33l
Copy link
Member

Dan33l commented Nov 29, 2018

I think we'll need the equivalent of puppetlabs/puppetlabs-apache#1848

For easily reading history of the PR , the job was done with PR #1277

@ekohl ekohl added the bug Something isn't working label Dec 15, 2018
@ekohl ekohl merged commit ce69db2 into voxpupuli:master Dec 15, 2018
@ekohl
Copy link
Member

ekohl commented Dec 15, 2018

Thanks!

@khaefeli
Copy link

Thanks for the fix. Could you please release it also to forge?
I lost much time because I only checked the open issues / PR and then started debugging my code, because I thought I'm on the latest 0.15.0 ;)

@SaschaDoering SaschaDoering deleted the 1274_fix_upstream_member_condition branch December 28, 2018 12:38
cegeka-jenkins pushed a commit to cegeka/puppet-nginx that referenced this pull request Sep 13, 2019
…mber_condition

Fix the condition for upstream members
Rubueno pushed a commit to Rubueno/puppet-nginx that referenced this pull request Oct 19, 2020
…mber_condition

Fix the condition for upstream members
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upstream members are never collected
4 participants