Hi,
Fuel has been using PDF and IDF for weeks now.
We still rely on net_config, which is out of spec, to map between PDF networks
and the network role within the installer.
Apart from net_config, we still need to sort out the mapping between interfaces
indexes in PDF and the interface names
Hi Jack and Infra team:
This week I have a chance to directly discuss with installer team: Apex and
Compass. I still can not contact Joid.
This is the status of PDF in each installer:
Apex: Not started, won't support in E release, and I have submitted a Jira
ticket in Apex.
Compass: Not
Hello,
I disagree to add variables in FROM instructions simply because it
obliges latest versions and then breaks Docker Automated builds.
It simply useless if we rely on Docker manifests as I have already demonstrated.
Manifest will also help jjobs as it avoids multiplying daily jjobs per arch.
All,
I'd like to propose having a discussion on user support in an upcoming TSC
call. We have two primary channels for user support which are opnfv-user
mailing list plus our Askbot site (https://ask.opnfv.org/questions/).
Over the past several quarters the activity on the Askbot site in
Question about best way to disable RPM builds in ovsnfv
In the August ovsnfv meeting we agreed to disable the building of OVS
and DPDK RPM artifacts within the ovsnfv project as this effort is
redundant with OVS RPMs found in downstream Centos repos.
Having received no negative public
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
Hello Alec,
Please find several answers inline.
Cédric
2017-10-14 20:55 GMT+02:00 Alec Hothan (ahothan) :
>
>
> Alex: this looks like a good plan and seems to take care of all functest
> requirements wrt build.
>
[Cédric]
Absolutly not as the second point is false from our
Hi,
During the E release cycle, Fuel and Armband projects merged their
documentation(s).
Currently, the contents of Fuel's 'docs/' dir describe usage for both
architecture.
To keep the old behavior unchanged, we duplicated that docs dir in Armband for
now.
Going forward, I think building the
I just want to simplify the tools, one use case with one tool.
If we have multiple choice, I don't know which will be chosen and which
will be supported. For an end user, I care about how long it will take me
to get the feedback for my question. It may have duplicated threads in the
different
I prefer to maintain it in installer project. If the affected content can
be documented in installer project properly, it will be easier for
maintainer, developer and end user.
Julien
Alexandru Avadanii 于2017年10月15日周日 下午11:27写道:
> Hi,
> During the E release cycle,
QTIP committers
There have been no further nominations for the QTIP PTL position. Therefore
Zhihui Wu is the sole candidate.
To provide a record of this and acknowledgement from QTIP committers please
vote on gerrit[1] indicating your approval/disapproval (+2, -2) for Zhihui
to take over as PTL
Hi Alex,
It's a great news.
2 PODs in our lab reserved for MCP are blocked to deploy in master branch.
Can you give me a PDF/IDF link which are used now, then we will submit
PDF/IDF patches according to your version.
For **net_config**, I personally suggest to move it to IDF and get the
Hi Mark,
It may be widely used in IT such as Image/Video/File storage. In NFV
scenario, Swift may be not a good use case.
Traditional telco products don't produce, transfer and consume these files.
Maybe it is useful in Edge computing.
Julien
Beierl, Mark 于2017年10月11日周三
Hi,
> -Original Message-
> From: Cedric OLLIVIER [mailto:ollivier.ced...@gmail.com]
> Sent: Sunday, October 15, 2017 8:27 PM
> To: Alec Hothan (ahothan)
> Cc: Alexandru Avadanii; Fatih Degirmenci; cedric.olliv...@orange.com; opnfv-
> tech-discuss; Delia Popescu; David McBride;
So far I have had a good experience with users reporting issues via JIRA. I
must admit the askbot site has not been very useful for me at this time.
Perhaps we need to highlight it more in the user guides? I know I have not
done that.
Regards,
Mark
Mark Beierl
SW System Sr Principal Engineer
Hi Serena,
It's a great news for TOSCA supported in Verigraph. It will make TOSCA
template more useful and enhance Parser ecosystem. Currently Parser is
integrating with ONAP project.
If it is reasonable, we can add it in Parser project. Let's discuss this
issue in email or with a meeting.
Alex,
Yes. You know I was waiting for tests from your side. As manifest works as
expected, we can remove most of them.
But I will keep the one to build/publish containers in any repo as it's very
useful.
My sentence was focused on Functest.
Cédric
Alexandru Avadanii a écrit
Hi,
Cédric,
I am curious, how does the manifest help with avoiding FROM? Is it that we
would use that to pull the correct base Alpine image?
Regards,
Mark
Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
Hello Mark,
Manifest allows pulling the right image according to ARCH
(arm64/amd64). Please see the dump of ollivier/functest-core:latest
attached to this mail.
Here I would like to avoid variables in FROM (by default) mainly to
ensure a better compatibility with all toolings and to ease
Hi Alex,
I think it makes sense for Armband team to have a separate documentation if
you are going have support of other installers (e.g. Apex or JOID) in the
future
I agree that replicating docs is wasteful, but do you think this would
continue beyond Euphrates?
Thanks,
Ray
On Sunday,
20 matches
Mail list logo