<div><div><div><div><br></div><div><br><div class="gmail_quote"></div></div></div><div><div dir="ltr" class="gmail_attr">On Tue, Nov 12, 2019 at 10:57 PM Numan Siddique <<a href="mailto:numans@ovn.org" target="_blank">numans@ovn.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Nov 13, 2019 at 12:02 AM Shivaram Mysore<br>
<<a href="mailto:shivaram.mysore@gmail.com" target="_blank">shivaram.mysore@gmail.com</a>> wrote:<br>
><br>
> No need to indicate "built on Ubuntu" for docker image tags.<br>
> Alpine tag is specifically used as it used different libraries and image size is small. Ideally, for Docker images, we should use Alpine Linux. If OVS for Alpine is latest, then image size will be further reduced.<br>
><br>
> Note thAt at the end of the day, container is just a delivery or packaging vehicle.<br>
><br>
> /Shivaram<br>
> ::Sent from my mobile device::<br>
><br>
> On Nov 12, 2019, at 9:49 AM, aginwala <<a href="mailto:aginwala@asu.edu" target="_blank">aginwala@asu.edu</a>> wrote:<br>
><br>
> <br>
> Thanks Shivaram:<br>
><br>
> On Tue, Nov 12, 2019 at 9:28 AM Shivaram Mysore <<a href="mailto:shivaram.mysore@gmail.com" target="_blank">shivaram.mysore@gmail.com</a>> wrote:<br>
>><br>
>> I am not sure why "*_debian" is used. The image should work across OS. I have not seen use of "*_linux" as most docker images use some form of shell scripts.<br>
>><br>
> Because the container image published is ubuntu and hence we tagged it with _debian. It doesn't indicate it will not work on rhel. If we all agree we can remove the tags and update the readme.md on <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a> that each container image is using ubuntu as base image. I am fine with any approach.<br>
>><br>
>> Also, in my opinion, the docker image should not build OVS. If it can add appropriate OVS packages like <a href="https://github.com/servicefractal/ovs/blob/master/Dockerfile" rel="noreferrer" target="_blank">https://github.com/servicefractal/ovs/blob/master/Dockerfile</a> is better as they are already tested. Building OVS as a part of this will cause more testing impacts and is unnecessary. The objective is to run OVS in a container image. I would keep it simple.<br>
<br>
I think the idea was to have an OVS container image with the latest<br>
master code right Aliasgar ?</blockquote></div></div></div><div><div><div><div dir="auto">Yes. E.g ovs docker image for ovs release 2.12.0 with debian/rhel will checkout v2.12.0 code from git and build it. That way source code will exist in docker image from which ovs2.12.0 will be installed on that container.</div></div></div></div><div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Getting OVS packages is good, but then the debian/ubuntu/fedora<br>
packages should be updated as soon as OVS does a release.</blockquote></div></div></div><div><div><div><div dir="auto">You mean to say e.g install with dpkg -i for latest version pushed using *2.12.0.deb for debian and skip building from source Code?</div></div><div dir="auto"><br></div><div dir="auto">So I think the open question now is; do we want to have source code in version specific container image with ovs installed from source code or we just need version specific ovs installed without source in the container?</div></div></div><div><div><div><div><div class="gmail_quote"><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks<br>
Numan<br>
<br>
>><br>
> I think the objective is to have an image per upstream stable ovs release and hence building it in container. Hope everyone is ok here.<br>
>><br>
>> On Tue, Nov 12, 2019 at 12:51 AM aginwala <<a href="mailto:aginwala@asu.edu" target="_blank">aginwala@asu.edu</a>> wrote:<br>
>>><br>
>>> Thanks Guru.<br>
>>><br>
>>> On Mon, Nov 11, 2019 at 1:03 PM Guru Shetty <<a href="mailto:guru@ovn.org" target="_blank">guru@ovn.org</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Mon, 11 Nov 2019 at 10:08, aginwala <<a href="mailto:aginwala@asu.edu" target="_blank">aginwala@asu.edu</a>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Mon, Nov 11, 2019 at 9:00 AM Guru Shetty <<a href="mailto:guru@ovn.org" target="_blank">guru@ovn.org</a>> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Fri, 8 Nov 2019 at 14:41, aginwala <<a href="mailto:aginwala@asu.edu" target="_blank">aginwala@asu.edu</a>> wrote:<br>
>>>>>>><br>
>>>>>>> openvswitch.ko ships default with newer kernel but if we want to use say stt, we need to build it with respective kernel for host on which we will run. Hence, to skip host level installation , we pack the modules in container.<br>
>>>>>><br>
>>>>>><br>
>>>>>> It is not clear to me. Is DKMS enabled here? Or is it that openvswitch/ovs:2.12.0_debian_4.15.0-66-generic will only work on kernel 4.15.0-66-generic?<br>
>>>>>><br>
>>>>><br>
>>>>> No. Dkms is not enabled because idea is to release a new docker image for every new kernel upgrade on compute (Not sure if dkms will help much in container case as we are not installing on host). Do you have any specific use case which? Yes on host with 4.15.0-66-generic.<br>
>>>><br>
>>>><br>
>>>> It will probably be very hard to release each OVS version to so many available kernels. How do you decide which kernel that you want to release a image for? What is the plan here? I think it makes sense to release one image without a kernel module packed with it.<br>
>>>><br>
>>> Agree, we can't publish too many images based on different kernel versions. Hence, I am ok with the approach you proposed by publishing single image for each stable release leveraging host kernel modules. I have pushed 2 debian images for each stable releases 2.11.2_debian and 2.12.0_debian under openvswitch/ovs accordingly. I also sent the corresponding patch <a href="https://patchwork.ozlabs.org/patch/1193372/" rel="noreferrer" target="_blank">https://patchwork.ozlabs.org/patch/1193372/</a> to refactor the docker builds to support an option to skip kernel modules for ovs repo so that user can choose to build/run with/without kernel modules. Let me know further.<br>
>>><br>
>>>><br>
>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> On Fri, Nov 8, 2019 at 2:37 PM Guru Shetty <<a href="mailto:guru@ovn.org" target="_blank">guru@ovn.org</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> On Fri, 8 Nov 2019 at 14:18, aginwala <<a href="mailto:aginwala@asu.edu" target="_blank">aginwala@asu.edu</a>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>> Hi all:<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> I have pushed two images to public openvswitch org on <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a> for ovs and ovn;<br>
>>>>>>>>> OVS for ubuntu with 4.15 kernel: openvswitch/ovs:2.12.0_debian_4.15.0-66-generic<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Why is the kernel important here? Is the OVS kernel module being packed?<br>
>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> run as : docker run -itd --net=host --name=ovsdb-server openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovsdb-server<br>
>>>>>>>>> docker run -itd --net=host --name=ovs-vswitchd --volumes-from=ovsdb-server --privileged openvswitch/ovs:2.12.0_debian_4.15.0-66-generic ovs-vswitchd<br>
>>>>>>>>><br>
>>>>>>>>> OVN debian docker image: openvswitch/ovn:2.12_e60f2f2_debian_master as we don't have a branch cut out for ovn yet. (Hence, tagged it with last commit on master)<br>
>>>>>>>>> Follow steps as per: <a href="https://github.com/ovn-org/ovn/blob/master/Documentation/intro/install/general.rst" rel="noreferrer" target="_blank">https://github.com/ovn-org/ovn/blob/master/Documentation/intro/install/general.rst</a><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> Thanks Guru for sorting out the access/cleanups for openvswitch org on <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a>.<br>
>>>>>>>>><br>
>>>>>>>>> We can plan to align this docker push for each stable release ahead.<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> On Fri, Nov 8, 2019 at 10:17 AM aginwala <<a href="mailto:aginwala@asu.edu" target="_blank">aginwala@asu.edu</a>> wrote:<br>
>>>>>>>>>><br>
>>>>>>>>>> Thanks Guru:<br>
>>>>>>>>>><br>
>>>>>>>>>> Sounds good. Can you please grant user aginwala as admin? I can create two repos ovs and ovn under openvswitch org and can push new stable release versions there.<br>
>>>>>>>>>><br>
>>>>>>>>>> On Fri, Nov 8, 2019 at 10:04 AM Guru Shetty <<a href="mailto:guru@ovn.org" target="_blank">guru@ovn.org</a>> wrote:<br>
>>>>>>>>>>><br>
>>>>>>>>>>> On Fri, 8 Nov 2019 at 09:53, Guru Shetty <<a href="mailto:guru@ovn.org" target="_blank">guru@ovn.org</a>> wrote:<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> I had created a openvswitch repo in docker as a placeholder. Happy to provide it to whoever the admin is.<br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>> i.e. You can use the keyword "openvswitch". For e.g., right now, it has one stale image.<br>
>>>>>>>>>>><br>
>>>>>>>>>>> docker run -d --net=none openvswitch/ipam:v2.4.90 /bin/sh -c "while true; do echo hello world; sleep 1; done"<br>
>>>>>>>>>>><br>
>>>>>>>>>>> So if we want the name "openvswitch", this is one option. If we prefer ovs/ovn or other keywords, then the admin can create a new one.<br>
>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> On Thu, 7 Nov 2019 at 13:15, aginwala <<a href="mailto:aginwala@asu.edu" target="_blank">aginwala@asu.edu</a>> wrote:<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Hi All:<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> As discussed in the meeting today, we all agreed that it will be a good idea to push docker images for each new ovs/ovn stable release. Hence, need help from maintainers Ben/Mark/Justin/Han to address some open action items as it is more of org/ownership/rights related:<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Get new repo created under <a href="http://docker.io" rel="noreferrer" target="_blank">docker.io</a> with name either ovs/ovn and declare it public repo<br>
>>>>>>>>>>>>> How about copy-rights for running images for open source projects<br>
>>>>>>>>>>>>> Storage: unlimited or some limited GBs<br>
>>>>>>>>>>>>> Naming conventions for docker images ;e.g openswitch/ovn:2.13.1_debian or openswitch/ovn:2.13.1_rhel. Similar for ovs.<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Once this is done, we can bundle docker image changes in the same release process<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Please feel free to add any missing piece.<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>>>> discuss mailing list<br>
>>>>>>>>>>>>> <a href="mailto:discuss@openvswitch.org" target="_blank">discuss@openvswitch.org</a><br>
>>>>>>>>>>>>> <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss" rel="noreferrer" target="_blank">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>
>>><br>
>>> _______________________________________________<br>
>>> discuss mailing list<br>
>>> <a href="mailto:discuss@openvswitch.org" target="_blank">discuss@openvswitch.org</a><br>
>>> <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss" rel="noreferrer" target="_blank">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>
><br>
> _______________________________________________<br>
> discuss mailing list<br>
> <a href="mailto:discuss@openvswitch.org" target="_blank">discuss@openvswitch.org</a><br>
> <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss" rel="noreferrer" target="_blank">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>
</blockquote></div></div>
</div>
</div>
</div>