-
-
Notifications
You must be signed in to change notification settings - Fork 161
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
Disallowing 1-primitive groups in cs_group is pointless #152
Comments
Having only one primitive in a group is a perfectly valid use case. For example, one might have constraints related to an arbitrary number of primitives created with create_resources, and the simplest way of doing that is to place them all of them in a group, and have the constraint point to that. Disallowing the possibility of ending up with just one primitive in the group does not make much sense. Update the check to allow 1-element arrays. Also, remove a misleading comment that also looks like it was copied from some other code that talked about colocations, not groups. Fixes issue voxpupuli#152.
For the stab I took at this that GitHub has duly cross-referenced, I of course forgot about Puppet's oh-so-smart single-element array munging as outlined in https://tickets.puppetlabs.com/browse/PUP-1299. |
Having only one primitive in a group is a perfectly valid use case. For example, one might have constraints related to an arbitrary number of primitives created with create_resources, and the simplest way of doing that is to place them all of them in a group, and have the constraint point to that. Disallowing the possibility of ending up with just one primitive in the group does not make much sense. Update the check to allow 1-element arrays. Also, remove a misleading comment that also looks like it was copied from some other code that talked about colocations, not groups. Fixes issue voxpupuli#152.
Having only one primitive in a group is a perfectly valid use case. For example, one might have constraints related to an arbitrary number of primitives created with create_resources, and the simplest way of doing that is to place them all of them in a group, and have the constraint point to that. Disallowing the possibility of ending up with just one primitive in the group does not make much sense. Update the check to allow 1-element arrays. Also, remove a misleading comment that also looks like it was copied from some other code that talked about colocations, not groups. Fixes issue voxpupuli#152.
As seen in voxpupuli/puppet-corosync#152, cs_group enforces a primitives array with a length >1. As a silly workaround, add a Dummy resource just so that the provider is happy.
As seen in voxpupuli/puppet-corosync#152, cs_group enforces a primitives array with a length >1. As a silly workaround, add a Dummy resource just so that the provider is happy.
Having only one primitive in a group is a perfectly valid use case. For example, one might have constraints related to an arbitrary number of primitives created with create_resources, and the simplest way of doing that is to place them all of them in a group, and have the constraint point to that. Disallowing the possibility of ending up with just one primitive in the group does not make much sense. Update the check to allow 1-element arrays. Also, remove a misleading comment that also looks like it was copied from some other code that talked about colocations, not groups. Fixes issue voxpupuli#152.
@fghaas are you interested in providing your patch as pull request? |
@igalic, do you have a workaround for PUP-1299 that works pre-4.0? |
no :( |
Is this still an issue? |
I believe so, yes. |
Having only one primitive in a group is a perfectly valid use case. For example, one might have constraints related to an arbitrary number of primitives created with create_resources, and the simplest way of doing that is to place them all of them in a group, and have the constraint point to that. Disallowing the possibility of ending up with just one primitive in the group does not make much sense. Update the check to allow 1-element arrays. Also, remove a misleading comment that also looks like it was copied from some other code that talked about colocations, not groups. Fixes issue voxpupuli#152.
Having only one primitive in a group is a perfectly valid use case. For example, one might have constraints related to an arbitrary number of primitives created with create_resources, and the simplest way of doing that is to place them all of them in a group, and have the constraint point to that. Disallowing the possibility of ending up with just one primitive in the group does not make much sense. Update the check to allow 1-element arrays. Also, remove a misleading comment that also looks like it was copied from some other code that talked about colocations, not groups. Fixes issue voxpupuli#152.
Having only one primitive in a group is a perfectly valid use case. For example, one might have constraints related to an arbitrary number of primitives created with create_resources, and the simplest way of doing that is to place them all of them in a group, and have the constraint point to that. Disallowing the possibility of ending up with just one primitive in the group does not make much sense. Update the check to allow 1-element arrays. Also, remove a misleading comment that also looks like it was copied from some other code that talked about colocations, not groups. Fixes issue voxpupuli#152.
closed by #368 |
Agreed. 👍 I'll leave this open for a time because I think I can produce a follow-up PR that saves a small amount of leg-work. |
Hmm, this should have auto-closed when #368 was merged. After all there is a comment to that effect in bd4268e. It looks like |
@ffrank, do you still want to produce a follow-up PR? |
The validation check in https://github.com/puppet-community/puppet-corosync/blob/master/lib/puppet/type/cs_group.rb#L30 is overzealous. It is a perfectly valid use case to have groups with just 1 primitive. For example, you might want to define a set of 3, 2 or even just 1 resource that you then reference from a constraint. The easiest way to that is to use a group, and to always have the constraint point to the group. If there is only one primitive in the group, so be it.
The alternative is to have manifests full of ifs and unlesses to either point to a group or to a standalone primitive, and that's just silly.
The text was updated successfully, but these errors were encountered: