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

2.0.2 instance types/counts + blueprint hook #160

Open
michaelmccaskill opened this issue Feb 10, 2021 · 2 comments
Open

2.0.2 instance types/counts + blueprint hook #160

michaelmccaskill opened this issue Feb 10, 2021 · 2 comments
Labels
TRIAGE: Hold Accepted, but delayed until further notice

Comments

@michaelmccaskill
Copy link

The blueprint hook tries to find instance counts/types and ultimately puts them in a runtime generated ops file. Unfortunately, this prevents me from using the same params concept for my counts/types for my isolation segments since it will error with:

[ERROR] No such instance group <instance I want> - cannot change instance counts to 6.
        Valid instance groups are:
          nats, diego-cell, diego-api, uaa, scheduler, router, api, cc-worker, adapter,
          doppler, log-api, tcp-router, credhub, haproxy
[ERROR] Could not determine which YAML files to merge: 'blueprint' hook exited with 1:
@dennisjbell
Copy link
Member

dennisjbell commented Feb 10, 2021

Yes, in this case, since you are already specifying the instance group directly in your environment to create an otherwise-unknown IG, you can specify the instance count directly inside its yaml block, and don't need to use the params helpers. Please let me know if that is not acceptable, and why.

@michaelmccaskill
Copy link
Author

I'm using my own ops file for creating an isolation segment. Something like this:

instance_groups:
- .: (( inject instance_groups.diego-cell ))
  name: system-diego-cell
  instances: (( grab params.system-diego-cell_instance_count || meta.defaults.system-diego-cell_instance_count ))

If I use params.system-diego-cell_instances the blueprint hook freaks out. I got around it by having to rename my parameter, which isn't great. My point is the blueprint hook shouldn't prevent me from using a preferred paradigm.

@mrferris mrferris added TRIAGE: Hold Accepted, but delayed until further notice and removed TRIAGE: More Information Needed labels Aug 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TRIAGE: Hold Accepted, but delayed until further notice
Projects
None yet
Development

No branches or pull requests

3 participants