#opnfv-bgs: Fuel OPNFV status No6
Meeting started by [1]JonasB at 14:01:34 UTC
(full logs).
Meeting summary
- RC2 status ([1]JonasB, 14:01:48)
- The full deploy chain is completed for libvirt,
"deploy.sh <iso>" will spin up the environment. (stefan_berg,
14:02:55)
- Fatih has integrated with Jenkins and we're
using blade 15 to test this. (stefan_berg,
14:03:25)
- The commit for this is finalized and ready for
approval/merge. (stefan_berg,
14:03:56)
- https://gerrit.opnfv.org/gerrit/#/c/306/
(stefan_berg,
14:04:00)
- The deploy is one Fuel master, three
controllers, two computes, full HA with Ceilometer. (stefan_berg,
14:04:52)
- first cut of documentation done and merged into
the repo. ([1]JonasB,
14:05:20)
- - comment on that (lmcdasm,
14:05:40)
- for nested environments with such a payload
(3x3 and that turned on) - have you done this anywhere before? I
have had failures (to to massive i/o wait at the disk, when trying
to fire three controllers on a single blade) (lmcdasm,
14:07:21)
- - on your own setup Sberg or elsewhere? - i
guess my question is more of - is that something we really want to
push - that layout - for nested environments. Judging from the
support questions we have receivd thus far, i can see it being a bit
of a hassle - can we simply have two profiles (a simple MultiNode -
no Ha and bells/whistles) and then the full HA one (lmcdasm,
14:09:29)
- - it will make sense in the long run cause we
can have simple test (smoke test) on smaller profile) and larger /
longer ones (lmcdasm,
14:09:52)
- I have now rebsed fuel due to upstream repo
changes ([1]JonasB,
14:10:05)
- The plan moving forward is to have the
"create_dea.sh" script detect also node roles, and then I'd suggest
to turn our example into a non HA one, that makes sense yes.
(stefan_berg,
14:11:05)
- - as part of my nested i will end up doing it
anyway (lmcdasm,
14:11:29)
- - since i will use your structure to pass a
common "profile" so that we dont have two different formats for two
different types (or other hypervisors we add later) (lmcdasm,
14:11:57)
- GREAT WORK DONE EVERYONE, REALLY
APPRECIATED! ([1]JonasB,
14:13:18)
- debootstrap patch ([1]JonasB, 14:14:02)
- https://gerrit.opnfv.org/gerrit/#/c/351/
(mskalski,
14:14:25)
- mskalski and all: Seems that you need to add
revievers, otherwise it is not vissible to others. I think that
behavior has changed in gerrit lately. ([1]JonasB,
14:17:48)
- Cento support ([1]JonasB, 14:19:51)
- Centos work will start from tomorrow.
([1]JonasB,
14:21:23)
- Auto deploy ([1]JonasB, 14:24:01)
- I'm adding the last bits for Autodeploy,
tommorrow I start testing on Nested Environment (SzilardCserey_ER,
14:27:33)
- but the Libvirt Adapters are missing, I will
take from Stefan's code and integrate it into mine (SzilardCserey_ER,
14:27:43)
- depending on which type of environment you want
to run it, you need either ESXi Adapters of Libvirt Adapters
(SzilardCserey_ER,
14:27:53)
- Tuning of how the libvirt DEA is created and
used at deploy. (stefan_berg,
14:29:16)
- Then looking into how to move forward together
with Daniel and Szilard for real iron deploy. (stefan_berg,
14:29:46)
- Hopefully the deployement logic of my libvirt
prototype can be reused for the main functionality. (stefan_berg,
14:30:47)
- - i have ciso and hp prototype (on/off attach
media) working - delivered for friday or monday along with esxi
adapter (lmcdasm,
14:31:17)
- - esxi adapter works, will rebase with
autodeployable ISO from SBerg and hook in a jenkins slave to esxi
for Friday (lmcdasm,
14:34:36)
- - HP adapter prototype work (API method) for
attach, on/off or (lmcdasm,
14:34:57)
- - Cisco done as well - only against
Simulator (lmcdasm,
14:35:09)
- - will merge Friday night and set
reviewers (lmcdasm,
14:35:18)
- yes (lmcdasm,
14:35:48)
- Lab status ([1]JonasB, 14:36:26)
- Daniel have the nested environment up,
documented on the Wiki ([1]JonasB,
14:48:19)
- https://wiki.opnfv.org/_media/get_started/opnfv_montreal_lab-revc.pdf
([1]JonasB,
14:49:38)
- - outstanding questions on the repo/web
server (lmcdasm,
14:51:37)
- Local repo mirror ([1]JonasB, 14:51:47)
- - system is ready and staged - need to know how
much / where desired clone point is (lmcdasm,
14:52:22)
- - as soon as input is received ITTE will set
firewall and we can point the build sytems at the CLONE_REPO in
config.mk (probably some nicer code if you want options as outlined
is good). (lmcdasm,
14:53:08)
- - will take about 1 hour once i create the
domain name for DNS around the world to update and we are in
business (lmcdasm,
14:53:31)
- http://docs.mirantis.com/fuel-dev/develop/env.html
(mskalski,
14:56:00)
- - the question is not just about the FUEL_REPO
Pointing - there are the other repos in config.mk and other upstream
items that we use. The question about what we are "snapshoting"
from upstream is more to the focus of my point (lmcdasm,
14:57:36)
- - for example other libs in our build, and do
we want to freeze other parts as well - working towards having the
structure that i outilned in the mail on the server for dealing with
control of the repo, etc. (lmcdasm,
14:58:26)
- - simply setting up a "mirror" of their Repo is
not what we want, otherwise we are just a hop in the chain - anyway
- if you can take a look at the mail and send me an answer to the
questions that would be wonderful. (lmcdasm,
14:59:27)
- - since a mirror (nightly) will change in sync
with others - we want to "freeze" frame the upstream and control it
- to match with released / builds (and now the auto-deploy and
testing parts). (lmcdasm,
15:00:07)
- ACTION: Jonas and
Daniel to come with a mirror strategy proposal ([1]JonasB,
15:00:21)
Meeting ended at 15:05:13 UTC
(full logs).
Action items
- Jonas and Daniel to come with a mirror strategy proposal
People present (lines said)
- [1]JonasB (59)
- lmcdasm (36)
- stefan_berg (20)
- SzilardCserey_ER (15)
- mskalski (10)
- fdegir (8)
- collabot (4)
Generated by MeetBot 0.1.4.