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

Controlling ipv6 support per environment has become cumbersome #270

Closed
ctheune opened this issue Jan 13, 2022 · 3 comments · Fixed by #323
Closed

Controlling ipv6 support per environment has become cumbersome #270

ctheune opened this issue Jan 13, 2022 · 3 comments · Fixed by #323
Milestone

Comments

@ctheune
Copy link
Member

ctheune commented Jan 13, 2022

With the new requirements to explicitly state whether IPv6/IPv4 is expected for a specific address we now need to introduce a lot of writing work to toggle this per environment (specifically when using dev containers which do not support IPv6 at all).

Need to review some deployments (e.g. directory and ask appops) to see what the writing looks like and how to provide a better toggle (on environment-basis?) to avoid if cascades both in the component code and potentially as well in the template code.

@ctheune ctheune added this to the batou 2.3 milestone Aug 23, 2022
@ctheune
Copy link
Member Author

ctheune commented Aug 23, 2022

I thought an improvement would be to provide multiple factories (like Address4, Address6, Address46) that are more explicit and can be used in settings like Attribute(Address4, ConfigString("{{host.fqdn}}")).

This is an improvement. However, this ticket is also about the issue that we need some flexibility whether a certain protocol may be optional in some environments (like v6 is required in production but optional or even not used in containers).

@ctheune
Copy link
Member Author

ctheune commented Aug 23, 2022

I think the factory idea is interesting, but I'm not adding them right away as I think it's wrong WRT to the whole signalling whether v6 is wanted or optional.

We might also want to change the resolution into something more lazy (but happens during configuration in any case, we might need to explicitly trigger all unresolved attributes when configuration finishes to make sure they don't pop up during deployment) so that we can rely on a single factory.

Laziness would allow us to also consider things from the environment (like making a general marker that this environment only supports v4 or v6 or both and make it optional or required if nothing else is required on a specific address. specific addresses then should use something like v4='required', v4='optional', v4=False, etc.

This could then be placed on an environment attribute, too:

[environment]
address-v4-default = required
address-v6-default = optional
; address-v6-default = unused

@ctheune
Copy link
Member Author

ctheune commented Sep 15, 2022

add migration info about how to restore old behaviour

ctheune added a commit that referenced this issue Sep 15, 2022
This allows a ternary option for required/unwanted/optional to deal
more cleanly with different situations.

We also allow switching the per-environment default from
v4=True/v6=False back to v4=True/v6=optional to avoid having to rewrite
older environments that rely on this while still introducing new
projects to the new settings by default and also suggesting that others
should upgrade eventually.

Fixes #270
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant