On Tue, Mar 26, 2024 at 7:09 PM Mark Michelson <mmich...@redhat.com> wrote:
> On 3/25/24 05:09, Ales Musil wrote: > > > > > > On Mon, Mar 25, 2024 at 9:47 AM Dumitru Ceara <dce...@redhat.com > > <mailto:dce...@redhat.com>> wrote: > > > > On 3/22/24 19:34, Mark Michelson wrote: > > > On 3/21/24 19:15, Dumitru Ceara wrote: > > >> Most of the steps were inaccurate. Instead, use latest Ubuntu, > use > > >> OVS from the submodule inside the OVN repo. > > >> > > >> Signed-off-by: Dumitru Ceara <dce...@redhat.com > > <mailto:dce...@redhat.com>> > > >> --- > > >> utilities/docker/Makefile | 4 ++-- > > >> utilities/docker/debian/Dockerfile | 2 +- > > >> utilities/docker/debian/build.sh | 2 ++ > > >> utilities/docker/install_ovn.sh | 31 > > ++++++++++++++---------------- > > >> 4 files changed, 19 insertions(+), 20 deletions(-) > > >> > > >> diff --git a/utilities/docker/Makefile > b/utilities/docker/Makefile > > >> index 57e95651cb..aad9c3482c 100644 > > >> --- a/utilities/docker/Makefile > > >> +++ b/utilities/docker/Makefile > > >> @@ -1,5 +1,5 @@ > > >> -#export OVN_BRANCH=master > > >> -#export OVN_VERSION=2.12 > > >> +#export OVN_BRANCH=main > > >> +#export OVN_VERSION=24.03.90 > > > > > > Is this something that we should update with each major release > > of OVN? > > > If so, I could probably alter my release script to include > updating > > > utilities/docker/Makefile as part of the release patches. > > > > > > > It's just a comment and I guess the original intention was to show > users > > how to set this up. But, back to your question, if it's not a lot of > > work, automatically changing this on release would be nice. > > > > Also, it might make sense to set up a CI job that actually runs this > in > > CI, maybe periodically. I can try to find some time to do that at > some > > point in the future. Wdyt? > > > > > > > > Hi Mark, Dumitru, > > > > from a different perspective, I would be interested to see if this is > > still used by anyone. We have other methods of running OVN in containers > > that are up to date and maintained. It might be the case of working > > perfectly, still used and doesn't need any attention. But it would > > probably still be useful to hear from the community if that's the case. > > IMO we shouldn't run CI on something just for the sake of running CI. > > > > Does that make sense? > > First off, with regards to this patch, I think it can be merged as-is, > with no further action. If we want to continue this discussion, we > shouldn't let it hold up the patch. > Yeah definitely, I don't want to block this at all, I was just curious. > When it comes to your questions, Ales, they're really hard to answer :) > > Is anyone using utilities/docker? I have no idea. I'd be willing to bet > most CMSes are using their own containerization methods instead of the > in-tree method. However, I don't know if there are people that use it > for development purposes. I know I tend to use ovn-fake-multinode during > development/testing, but that's just me. > > When you mention having other methods of running OVN in containers, are > you referring to the content in utilities/containers ? I was mainly referring to ovn-fake-multinode in that case. > I agree that when > it comes to CI, we probably don't need the content in utilities/docker . > But it appears to have been written to be a general-purpose method of > creating versioned container builds of OVN, rather than specifically for > CI. The content in utilities/docker is also quite out of date, I would > imagine, since it hasn't been updated since adding cluster support in > January 2020. There is also documentation throughout the tree that > refers to the content in utilities/docker. If a new user were to > download the OVN source and browse the documentation, they would try to > use the Makefile in utilities/docker. > > In my opinion, the best thing to do is to merge the two containerization > methods together into a single unified method. We can then use this for > our CI, meaning we will keep it up to date and add necessary features as > we see fit. This way we aren't keeping a "dead" method alive in the tree > for no reason, and we won't be adding unnecessary CI either. > > What do you think? > I'm not sure merging is the right thing, as there is probably not one size to fit them all. We could certainly change the documentation with reference to the utilities/containers as a way to have reproducible builds. Anyway let's proceed with the series as is and we can always follow up with other ideas for this area. > > > > > > > >> #export DISTRO=debian > > >> #export GITHUB_SRC=https://github.com/ovn-org/ovn.git > > <https://github.com/ovn-org/ovn.git> > > >> #export DOCKER_REPO=ovn-org/ovn > > >> diff --git a/utilities/docker/debian/Dockerfile > > >> b/utilities/docker/debian/Dockerfile > > >> index 366ad6d4f3..a89ef46c9f 100644 > > >> --- a/utilities/docker/debian/Dockerfile > > >> +++ b/utilities/docker/debian/Dockerfile > > >> @@ -1,4 +1,4 @@ > > >> -FROM ubuntu:16.04 > > >> +FROM ubuntu:22.04 > > >> MAINTAINER "Aliasgar Ginwala" <aginw...@ebay.com > > <mailto:aginw...@ebay.com>> > > >> ARG OVN_BRANCH > > >> diff --git a/utilities/docker/debian/build.sh > > >> b/utilities/docker/debian/build.sh > > >> index 57ace5f505..6edb5b85e4 100755 > > >> --- a/utilities/docker/debian/build.sh > > >> +++ b/utilities/docker/debian/build.sh > > >> @@ -12,6 +12,8 @@ > > >> # See the License for the specific language governing > > permissions and > > >> # limitations under the License. > > >> +set -e > > >> + > > >> OVN_BRANCH=$1 > > >> GITHUB_SRC=$2 > > >> diff --git a/utilities/docker/install_ovn.sh > > >> b/utilities/docker/install_ovn.sh > > >> index 55c189aaee..5157da1497 100755 > > >> --- a/utilities/docker/install_ovn.sh > > >> +++ b/utilities/docker/install_ovn.sh > > >> @@ -12,29 +12,26 @@ > > >> # See the License for the specific language governing > > permissions and > > >> # limitations under the License. > > >> +set -e > > >> + > > >> OVN_BRANCH=$1 > > >> GITHUB_SRC=$2 > > >> -# get ovs source always from master as its needed as > dependency > > >> -mkdir /build; cd /build > > >> -git clone --depth 1 -b master > > https://github.com/openvswitch/ovs.git > > <https://github.com/openvswitch/ovs.git> > > >> -cd ovs; > > >> -mkdir _gcc; > > >> +# Get ovn source. > > >> +git clone --depth 1 -b $OVN_BRANCH $GITHUB_SRC > > >> +cd ovn > > >> -# build and install > > >> +# Get OVS submodule, build and install OVS. > > >> +git submodule update --init > > >> +cd ovs > > >> ./boot.sh > > >> -cd _gcc > > >> -../configure --localstatedir="/var" --sysconfdir="/etc" > > >> --prefix="/usr" \ > > >> +./configure --localstatedir="/var" --sysconfdir="/etc" > > --prefix="/usr" \ > > >> --enable-ssl > > >> -cd ..; make -C _gcc install; cd .. > > >> - > > >> +make -j8 install > > >> +cd .. > > >> -# get ovn source > > >> -git clone --depth 1 -b $OVN_BRANCH $GITHUB_SRC > > >> -cd ovn > > >> - > > >> -# build and install > > >> +# Build and install OVN. > > >> ./boot.sh > > >> ./configure --localstatedir="/var" --sysconfdir="/etc" > > >> --prefix="/usr" \ > > >> ---enable-ssl --with-ovs-source=/build/ovs/ > > >> --with-ovs-build=/build/ovs/_gcc > > >> -make -j8; make install > > >> +--enable-ssl > > >> +make -j8 install > > > > > > > _______________________________________________ > > dev mailing list > > d...@openvswitch.org <mailto:d...@openvswitch.org> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > <https://mail.openvswitch.org/mailman/listinfo/ovs-dev> > > > > > > Thanks, > > Ales > > -- > > > > Ales Musil > > > > Senior Software Engineer - OVN Core > > > > Red Hat EMEA <https://www.redhat.com> > > > > amu...@redhat.com <mailto:amu...@redhat.com> > > > > <https://red.ht/sig> > > > > Thanks, Ales -- Ales Musil Senior Software Engineer - OVN Core Red Hat EMEA <https://www.redhat.com> amu...@redhat.com <https://red.ht/sig> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
