|
Bin,
Can we add this topic to the Tech Discuss meeting this week?
Perhaps, after the Clover topic? thanks
Topic is IDF definitions and details (others feel free to add/adjust)
On 10/16/2017 06:49 AM, Julien wrote:
Hi David,
I agree your comments about net_config in [2]. Before my
holiday maybe I make a mistake that I think IDF is used for
infrastructure network descriptor.
For Jobs naming, I think in Kubernetes, we still need to
resolve the usage of network and storage, while these features
are not well supported in the Kubernetes community. Control is
equivalent to Master, and Minion is equivalent to Minion. It
is difficult to define one set of names to meet all the
requirement. If someday VMware or HyperV is introduced into
the community as VIM, the names are meaningful to the new
VIMs?
Hi everyone,
I agree that the PDF/IDF definitions must be fixed
ASAP.
- About net_config in IDF: I think it is a bad
idea. As i answer in the patch #42233 [2], if the L3
network is configured in the infra (firewall, router,
...), and not configurable by the installer, it must
stay in the PDF. If the PDF leaves an empty L3 network
section, it could be fixed by the installer, and
configured in the IDF.
- About net_config as proposed by Guillermo
Herrero in #42893 [1]: +1 with an official
naming less openstack 'like'. For a better
understanding and writing by infra ops, can we
authorize comments describing what is this network in
simple name (and openstack 'like' naming if the author
like it)? We must consider that ops may not use the
same convention in the data center, and pdf writting
must not be painful.
- Jobs naming: Today, jobs in IDF are also
openstack centric and can only describe a ha or noha
mode, but not both, I propose in #42233[2] that we use
'infra', 'worker' and 'infra_or_worker' as naming for
main node's job. This will let SDF file describing
what is the mapping to openstack, k8s or any other
vim naming.
- storage definition in shared IDF part [3]:
Julien propose to add the storage definition in IDF, I
agree, but it must be consolidated. I will comment in
the patch
BR
David
[1]
https://gerrit.opnfv.org/gerrit/#/c/42893
[2]
https://gerrit.opnfv.org/gerrit/#/c/42233
[3]
https://gerrit.opnfv.org/gerrit/#/c/44603/1/labs/att/idf-pod1.yaml
--
David BLAISONNEAU
NFV platforms DevOPS - OPNFV contributor
Orange - IMT / OLN / CNC / NCA / SINA
tel: +33 (0)2 96 07 27 93
email: [email protected]
2, avenue Pierre Marzin 22307 LANNION Cedex - France
Le
16/10/2017 à 02:25, Julien a écrit :
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 template/format approved ASSP,
for it is really important to us.
BR/Julien
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 inside OS (e.g.
iface 0 = eno1, iface 2 = enp1s0f1).
For
net_config, Guillermo proposed an
alternative as a comment in [1], which imo
is closer to the hardware view of the setup
(especially the port_matrix part).
For
iface name mapping, we will probably add it
to IDF as a Fuel-specific section for now
(no PoC proposed yet).
BR,
Alex
[1]
https://gerrit.opnfv.org/gerrit/#/c/42893/6/labs/lf/pod4.yaml
From: [email protected]
[mailto:[email protected]]
On Behalf Of Julien
Sent: Sunday, October 15, 2017
12:38 PM
To: Jack Morgan;
opnfv-tech-discuss
Subject: Re:
[opnfv-tech-discuss] [Infra] Infra WG
Weekly Meeting Minutes - Oct. 9th
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 started,
and plan to support in F release
Daisy: PDF is
supported and used in CI PODs for
deployment, while IDF is not used for
now
Fuel: Started, not
finished yet
Joid: No response in
email and IRC(#opnfv-joid)
I would like to
suggest to clear PDF/IDF patches in
gerrit, let's make an acceptable
template and update them in the future,
then the lab owners can submit their
PDF/IDF and used for deployment.
October
9th
Agenda:
1.
Status
update on PDF
·
complete
discussion from last week as
this is a deliverable for
Euphrates release
3.
Infra
documentation on RTD - patch 40329 merged, what
else?
a.
Discussion
of Infra documentation
4.
Zuul
v3, Fatih
Degirmenci
.
possibility
to start a prototype?
5.
Follow
up on security audit job
logs ![]() RELENG-272 - Ericsson
Build 3 not reporting
failures to comments IN
PROGRESS
6.
F
Release participation
7.
Review
actions items
Minutes
(link)
1.
Status
update on PDF
2.
LaaS
and Dashboard integration
·
lylavoie
is working on LF hosting
issues with bramwelt but
will focus on it after the
release
·
requirements
gathering and plan is being
tracked via Dashboard Roadmap
3.
Infra
documentation on RTD
·
initial patch 40329 has been
merged, what else needs to
be migrated
·
bramwelt
has some documentation to post
but not sure which project it
goes
·
bryan_att
mentioned that the Equifax
breach was due to Apache
structs vulnerability
·
bryan_att
suggests we need some
discussion on potential
scanner tools for production
deployments
·
Luke
will investigate ODL
scanning and bryan_att will
bring it up at the TSC
·
jmorgan1
mentions this is a good
Plugfest topic
·
contact
installer PTLs support of
PDF in Euphrates
·
Fuel/MCP
and Daisy4NFV has support
for PDF, Compass4NFV will
delay working on it until F
release
·
Apex
and Joid have not responded
to emails
·
closed
and new action items below
Closed
Actions:
·
Contact
installer PTLs for support of
PDF in Euphrates julien
zhang
·
Submit
patches to add lab owners and
others to Pharos repo Aric
Gardner
·
Reach
out to lab owners to collect
feedback on including username
and password in PDF Jack
Morgan
·
Reach
out to Luke
Hinds to
security projects input on
passwords in PDF Aric
Gardner
·
Create
wiki page to track next steps
and features for
Laas/dashboard effort Lincoln
Lavoie
·
Reach
out to Joid, Apex and Compass
need to provide a contact for
PDF effort julien
zhang
·
create POC
on encryption option Aric
Gardner
·
New
Actions:
--
Jack Morgan
OPNFV Pharos Intel Lab
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
--
Jack Morgan
OPNFV Pharos Intel Lab
|
