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

Generate predeployed Kuberntes Images based on kubeadm separately #564

Closed
rmohr opened this Issue Nov 9, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@rmohr
Member

rmohr commented Nov 9, 2017

Goals are:

  1. Make it simpler to change kubevirt manifests without having to think about cleaning an already deployed version
  2. Decouple k8s deployment errors from KubeVirt errors
  3. Gain a permanent caching benefit by always using preprovisioned k8s images
@rmohr

This comment has been minimized.

Show comment
Hide comment
@rmohr
Member

rmohr commented Nov 9, 2017

@fabiand

This comment has been minimized.

Show comment
Hide comment
@fabiand

fabiand Nov 13, 2017

Member

@rmohr could you explain this issue a little more? The issue and the solution you have in mind.

Member

fabiand commented Nov 13, 2017

@rmohr could you explain this issue a little more? The issue and the solution you have in mind.

@rmohr

This comment has been minimized.

Show comment
Hide comment
@rmohr

rmohr Nov 13, 2017

Member

Sure. It has its own complexity to deploy k8s. Kubeadm can have an issue, the newest k8s release can have an issue. Further we need to test against different k8s versions, different open shift versions and (probably) different network providers in the future. Therefore having dedicated jobs, which re-create/update base images with k8s periodically and do basic sanity checks, we can make our testing more resilient against external issues and always have the advantage that the images are already ready for KubeVirt. We also don't have to take care about removing our testing traces from the image, since we can just do a vagrant destroy && vagrant up.

Member

rmohr commented Nov 13, 2017

Sure. It has its own complexity to deploy k8s. Kubeadm can have an issue, the newest k8s release can have an issue. Further we need to test against different k8s versions, different open shift versions and (probably) different network providers in the future. Therefore having dedicated jobs, which re-create/update base images with k8s periodically and do basic sanity checks, we can make our testing more resilient against external issues and always have the advantage that the images are already ready for KubeVirt. We also don't have to take care about removing our testing traces from the image, since we can just do a vagrant destroy && vagrant up.

@rmohr

This comment has been minimized.

Show comment
Hide comment
@rmohr

rmohr Nov 13, 2017

Member

For as long as we are using vagrant, we can e.g. do a vagrant up, wait until the provision script succeeds and then upload the result to vagrant cloud with the appropriate version tag. If we move over to do something more like Cockpit does, we can host the images somewhere else.

Member

rmohr commented Nov 13, 2017

For as long as we are using vagrant, we can e.g. do a vagrant up, wait until the provision script succeeds and then upload the result to vagrant cloud with the appropriate version tag. If we move over to do something more like Cockpit does, we can host the images somewhere else.

@fabiand

This comment has been minimized.

Show comment
Hide comment
@fabiand

fabiand Nov 14, 2017

Member

Thanks for clarifying this.

Member

fabiand commented Nov 14, 2017

Thanks for clarifying this.

@fabiand

This comment has been minimized.

Show comment
Hide comment
@fabiand

fabiand Apr 4, 2018

Member

@rmohr I think this is done,r ight?

Member

fabiand commented Apr 4, 2018

@rmohr I think this is done,r ight?

@rmohr

This comment has been minimized.

Show comment
Hide comment
@rmohr

rmohr Apr 4, 2018

Member

Yes done. We only need to officially deprecate vagrant now #844.

Member

rmohr commented Apr 4, 2018

Yes done. We only need to officially deprecate vagrant now #844.

@rmohr rmohr closed this Apr 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment