Closed unclejack closed 6 years ago
build PR
Since this is pretty standalone, can we create a repo for ovs container (or fork a upstream one) instead ? this way could keep thie repo only for netplugin/netmaster codes
We can't use any upstream image. This is tightly coupled with our netplugin setup. It puts logs in the contiv directory. We also need to use a version which has been tested with netplugin.
Actually other than logging dir this is a pretty common ovs configuration (and we can update entrypoint if we wanted), we can customized base on an upstream repo to avoid maintain generic containers, also we can move it out of release scope, let (active) upstream to do security upgrading and all we need to do is to make sure it works for contiv. It's fine to put this fully under control if you think it's really needed, but could you please make it in different repo ? It's really a generic component doesn't have to be in netplugin repo
I've worked on this because it was part of some work which was needed to be finished soon. I can close this PR and attempt to create a repository for this.
I agree with Wei. If there is a way for us to use a generic OVS container, and customize for our environment where needed, that would be better than us maintaining our own builds/repo/etc. Also, I'm wondering why the OVS logs have to be in the contiv dir?
@amccormi that directory is bindmounted from the host... otherwise we would lose the logs if the container crashed/restarted
I'll close this now. The image will live in a separate repository.
This PR adds support for building a standalone openvswitch image and it adds a new target to the list of CI targets.
The PR also modifies scripts/netContain/build_image.sh. That change makes it load the openvswitch kernel module only if it's not loaded.