You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently zarf packages can be created and packaged with custom data to be injected using the DataInjection feature. This is a already a great feature as we can package additional scripts and files to be run at deploy time.
This feature request is about extending this functionality so that on-premises data that is not known at package creation can be injected from outside the zarf package itself. This will allow users to deploy data that is only available at the on-premises / air-gapped site. For example, data that is not available for privacy/security/ownership reasons.
Describe the solution you'd like
Since a package creator cannot pre-pack all the data needed for a zarf deployment, we should add an option to `zarf package deploy' to define the data we want to inject via a CUSTOM environment variable or similar. I imagine that this env variable points to a directory relative to the zarf binary or the zarf package file location. In the zarf package itself, this env is defined as the source of the data. Optionally, we could limit the files and directories injected using file/dir pattern matching, similar to .gitignore matching.
If possible, the injected data should be available before the main container process starts (as it is now with the existing DataInjection functionality).
Describe alternatives you've considered
As a workaround to this solution I've recently created a zarf package which deploys a complete zarf manifest including a datainjection job to the air-gapped system. On the air-gapped system I then do a zarf package create in order to inject the data we want. Once we have the newly created package we deploy it using zarf package deploy. It works but this workaround is rather tedious to setup and maintain.
Additional context
This feature has already been briefly discussed on the zarf slack channel here
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently zarf packages can be created and packaged with custom data to be injected using the DataInjection feature. This is a already a great feature as we can package additional scripts and files to be run at deploy time.
This feature request is about extending this functionality so that on-premises data that is not known at package creation can be injected from outside the zarf package itself. This will allow users to deploy data that is only available at the on-premises / air-gapped site. For example, data that is not available for privacy/security/ownership reasons.
Describe the solution you'd like
Since a package creator cannot pre-pack all the data needed for a zarf deployment, we should add an option to `zarf package deploy' to define the data we want to inject via a CUSTOM environment variable or similar. I imagine that this env variable points to a directory relative to the zarf binary or the zarf package file location. In the zarf package itself, this env is defined as the source of the data. Optionally, we could limit the files and directories injected using file/dir pattern matching, similar to .gitignore matching.
If possible, the injected data should be available before the main container process starts (as it is now with the existing DataInjection functionality).
Describe alternatives you've considered
As a workaround to this solution I've recently created a zarf package which deploys a complete zarf manifest including a datainjection job to the air-gapped system. On the air-gapped system I then do a
zarf package create
in order to inject the data we want. Once we have the newly created package we deploy it usingzarf package deploy
. It works but this workaround is rather tedious to setup and maintain.Additional context
This feature has already been briefly discussed on the zarf slack channel here
The text was updated successfully, but these errors were encountered: