Alec,
We appreciate your comments. In the Armband project, we indeed
used x86 jump servers for the first 2 years of the project, but converted to
ARM servers recently as we resolved missing support items. It is our preference
at this point to identify and resolve missing ARM support wherever we encounter
it, rather than decide we cannot do it. OPNFV, ONAP, FD.IO, DPDK, etc shall
be/must be multi-architecture and our team can help bring resources to bear to
solve the problems as they arise.
Having said that, if we have a deadline that will be missed due
to lead times to solve ARM support issues, we can always decide to attack that
offline for a later release.
I am on holiday and I will ask Shai Tsur and Alex Avadanii to
help dealing with identified issues that require work. Shai, please escalate
internally if we need extra resources to solve issues.
Regards,
Bob
Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman
From: [email protected]
[mailto:[email protected]] On Behalf Of Alec Hothan
(ahothan)
Sent: Wednesday, August 16, 2017 5:47 PM
To: HU, BIN <[email protected]>; Beierl, Mark <[email protected]>
Cc: [email protected]
Subject: Re: [opnfv-tech-discuss] Topics for Weekly Technical Discussion
Mark,
Thanks for updating me on the ARM situation. My only comment is that it could
have been easier to perhaps have an x86 server/jump host servicing an ARM pod
given that testing tools do not exactly have to run on the same arch than the
pod under test, but I guess decision has been made - now we need every test
tool to also support ARM (that in addition to more work to support 2 arch, more
test to do…).
On my side, I’ll need to check with the TRex team if they support ARM. If it
does not work, every data plane test tool that uses TRex will be impacted (at
least vsperf + nfvbench).
It really seems to me that we could have saved all the extra hassle of ARM
support with an x86 jump host (VMs is another story but we could have limited
the overhead to VM artifacts only).
Bin: unfortunately, I won’t be able to make it at the technical discussion
meeting as it will be in the middle of my Thursday commute.
Thanks
Alec
From: "HU, BIN" <[email protected]<mailto:[email protected]>>
Date: Tuesday, August 15, 2017 at 5:00 PM
To: "Beierl, Mark" <[email protected]<mailto:[email protected]>>, "Alec
Hothan (ahothan)" <[email protected]<mailto:[email protected]>>
Cc:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: RE: [opnfv-tech-discuss] Topics for Weekly Technical Discussion
Good discussion and suggestion, thank you Alec and Mark.
We can discuss this on Thursday. I put it on the agenda “Container Versioning /
Naming Schema for x86 and ARM”.
Talk to you all on Thursday
Bin
From: Beierl, Mark [mailto:[email protected]]
Sent: Tuesday, August 15, 2017 10:23 AM
To: Alec Hothan (ahothan) <[email protected]<mailto:[email protected]>>
Cc: HU, BIN <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: Re: [opnfv-tech-discuss] Topics for Weekly Technical Discussion
Hello, Alec.
Fair questions, but in the ARM pods there are not necessarily x86 servers to
act as the host for the container. It is also my desire to support ARM for the
various pods we have, and not make it difficult for them to run. We already
support ARM containers for functest, yardstick, qtip and dovetail, just with a
different naming scheme than other projects in docker hub.
If you look at the way multiarch alpine structures their tags, yes, it is
arch-version, so x86-euphrates.1.0 would be the correct way of labelling it. I
realize we are getting close to Euphrates release date, so this might be
postponed to F, but I would like to have a community discussion about this to
see if it makes sense, or if we want to continue with creating repos to match
the architecture.
Regards,
Mark
Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106<tel:1-613-314-8106>
[email protected]<mailto:[email protected]>
On Aug 15, 2017, at 12:03, Alec Hothan (ahothan)
<[email protected]<mailto:[email protected]>> wrote:
We need to look at the impact on versioning since the docker container tag
reflects the release (e.g. euphrates-5.0.0), since this proposal prepends an
arch field (x86-euphrates-5.0.0 ?).
How many OPNFV containers will have to support more arch than just x86?
I was under the impression that most test containers could manage to run on x86
only (since we can pick the server where these test containers will run), but I
am missing the arm context and why (some) test containers need to support ARM…
Is that a mandate for all OPNFV test containers?
Thanks
Alec
From:
<[email protected]<mailto:[email protected]>>
on behalf of "Beierl, Mark" <[email protected]<mailto:[email protected]>>
Date: Tuesday, August 15, 2017 at 8:18 AM
To: "HU, BIN" <[email protected]<mailto:[email protected]>>
Cc:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [opnfv-tech-discuss] Topics for Weekly Technical Discussion
Hello,
Is this the right place to discuss changing the docker image names from
containing the architecture to having the tag contain it instead? For example
(from a previous email):
Alpine tags as follows:
multiarch/alpine:x86-latest-stable
multiarch/alpine:aarch64-latest-stable
Vs. in OPNFV we use the image name to specify the architecture [2], [3]:
opnfv/functest:latest
opnfv/functest_aarch64:latest
I think the way multiarch/alpine does it is preferable so that there is only
one repository name, but I think we need to discuss this across the different
projects and releng to make these changes.
[1]
https://hub.docker.com/r/multiarch/alpine/tags/<https://urldefense.proofpoint.com/v2/url?u=https-3A__hub.docker.com_r_multiarch_alpine_tags_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=MJxkjW6BJzaG06zvgFQAVZz8mxuxlsgLJDxEloQq8AE&s=K5o_APjIzMi4SzYSdQvcyR3VrIJFwSZZtcD-7MXnchA&e=>
[2]
https://hub.docker.com/r/opnfv/functest/<https://urldefense.proofpoint.com/v2/url?u=https-3A__hub.docker.com_r_opnfv_functest_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=MJxkjW6BJzaG06zvgFQAVZz8mxuxlsgLJDxEloQq8AE&s=jQw8zZteD7PMN01Zl7Ey5NDM8EO6r8UOcNUPSZGvY3M&e=>
[3]
https://hub.docker.com/r/opnfv/functest_aarch64/tags/<https://urldefense.proofpoint.com/v2/url?u=https-3A__hub.docker.com_r_opnfv_functest-5Faarch64_tags_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=MJxkjW6BJzaG06zvgFQAVZz8mxuxlsgLJDxEloQq8AE&s=2V36PQtXGS40gTA_NGCBO1nKZsI5yHgB3jFxrWajy6k&e=>
Regards,
Mark
Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106<tel:1-613-314-8106>
[email protected]<mailto:[email protected]>
On Aug 15, 2017, at 10:52, HU, BIN <[email protected]<mailto:[email protected]>>
wrote:
Hello community,
Just a friendly reminder that if you want to discuss any item/topic/issue at
our weekly technical discussion this Thursday 08/17, please feel free to let me
know.
Thanks
Bin
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]<mailto:[email protected]>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opnfv.org_mailman_listinfo_opnfv-2Dtech-2Ddiscuss&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1K_r6YIIHhw&m=MJxkjW6BJzaG06zvgFQAVZz8mxuxlsgLJDxEloQq8AE&s=vRFVyjqXc-ThbnFiI_m1-lhsgnPWftV4M7TgUFAA8vY&e=>
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
