14:00:50 <[1]JonasB> #startmeeting fuelstatusNo2
14:00:50 <collabot> Meeting started Mon Apr 13 14:00:50 2015 UTC.  The chair is [1]JonasB. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:50 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:50 <collabot> The meeting name has been set to 'fuelstatusno2'
14:00:58 <[1]JonasB> So lets start
14:01:17 <Szilard> ok
14:01:22 <lmcdasm> #agreed
14:01:37 <[1]JonasB> Is mskalski online?
14:01:50 <mskalski> [1]JonasB: yes I m
14:02:03 <lmcdasm> Current Lab Status:
14:02:08 <lmcdasm> oops mt sorry
14:02:16 <[1]JonasB> Cool, lets start with the install issue
14:02:24 <[1]JonasB> #topic Install issue
14:02:30 <mskalski> I can confirm that using iso from Stefan I successfully deploy environment
14:03:08 <mskalski> but still don't know why my and RC0 build were broken
14:03:10 <[1]JonasB> #info so stefan_berg has checked the diff, and he says the two are identical. Just a matter of ordering
14:03:52 <[1]JonasB> This is really interesting!
14:03:57 <lmcdasm> hmm.. do you have debbootstrap packages installed on your machine?
14:04:24 <lmcdasm> im wondering .. since i havent had an issue with baremetal or vm environment (straight virsh as well today seems ok to me).
14:04:36 <lmcdasm> your *build machine* that is
14:05:39 <mskalski> dpkg -l does not show any debootstrap package, but build is run inside docekr container right?
14:05:51 <lmcdasm> i know.. im just trying to pick differences
14:06:19 <lmcdasm> what i can do.. it put a ova of my build server into one of the labs (3/4 blades are done installing) and you can try building from there / seeing the difference
14:06:33 <[1]JonasB> #info Michal can Install Stefans Image, but not the one he built itself, which again are identical except for the order in the ubuntu-versions.yaml file.
14:06:45 <lmcdasm> hmm.
14:06:53 <lmcdasm> its gotta be hw / env related them
14:06:54 <lmcdasm> then*
14:07:04 <lmcdasm> something about his mkiso libraries or lib path is wrong
14:07:13 <lmcdasm> in the creation of the mkfs.iso i think
14:07:26 <lmcdasm> we can truss / sh -x debug his build and go hunting
14:07:27 <[1]JonasB> What is the best way forward to capture this issue now?
14:07:28 <mskalski> we need to remeber that also  jenkins produced broken image
14:07:40 <lmcdasm> hmm.. good point
14:07:46 <lmcdasm> well.. i am all about standardizing..
14:07:57 <lmcdasm> we should all move to a defalt build server type in the labs i would say
14:08:04 <lmcdasm> then we rule out stuff and build off one common set
14:08:21 <lmcdasm> <just an opinion - cause we could chase environments for a while and less is more>
14:08:32 <[1]JonasB> mskalski: Yes, good point
14:09:10 <[1]JonasB> Have anyone deployed a jenkins produced image or have everyone jusst built on their own gear?
14:09:25 <lmcdasm> i have only done it back when it was first setup
14:09:36 <lmcdasm> its something we can try and focus as a priority to fix
14:09:52 <lmcdasm> and from there ghost / image the jenkins build environment ?
14:10:11 <[1]JonasB> Fdegir: where can we find daylies
14:11:43 <[1]JonasB> That yaml file is generated during build, right.
14:12:07 <mskalski> stefan_berg: you deployed rc0 from jenkins and also confirmed that it was broken right?
14:12:44 <[1]JonasB> mskalski: That is right!
14:13:31 <[1]JonasB> mskalski: And you also confirmed that stefans build did deploy, right?
14:13:43 <mskalski> [1]JonasB: yes
14:14:35 <[1]JonasB> And now we have the diff from the two, and the only thing that differs seems to be the order in the yaml file.
14:14:49 <lmcdasm> i wonder if the broken rc0 build and michal's issue arent seperate (rc0 being transient bad build?) - we can retest with daily
14:15:03 <fdegir> sorry, in octopus meeting
14:15:39 <[1]JonasB> fdegir: Where is your multitasking:-)
14:15:40 <mskalski> all this problems during debootsrap is because postinstalation scripts of  base-files is run before base-passwd is installed, so order does matter
14:16:09 <mskalski> but I don't know if this ubuntu-versions.yaml is resposible for that
14:16:18 <[1]JonasB> mskalski: That's valuable info!
14:17:31 <mskalski> it is the same situation as described here: https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1001131
14:17:40 <[1]JonasB> mskalski: Would a way forward be to take your iso that doesnt install, loopback mount it and replace the yaml file from that in stefans iso and try to install it?
14:18:03 <mskalski> [1]JonasB: i can try this
14:20:51 <[1]JonasB> #info Michal will try to replace the ubuntu-versions.yaml file in his non installable image to that of the yaml file in Stefans iso.
14:21:04 <[1]JonasB> Next - server/POD status
14:21:16 <[1]JonasB> #topic lab status
14:21:26 <[1]JonasB> Daniel, shoot.
14:23:03 <lmcdasm> yup
14:23:10 <lmcdasm> sorry was on other screen installing
14:23:34 <lmcdasm> 5/7 servers installed for nested environment 60/40 split esxi and ubuntu (one centos base as well)
14:23:47 <[1]JonasB> lmcdasm: Your installing blade 9-16 right.
14:24:02 <lmcdasm> each environment will have its one vrouter front facing (vyatta or quagga as you prefer)
14:24:18 <lmcdasm> and its own "sandbox of routable internet" each.
14:24:39 <[1]JonasB> I have no preference. But no L2 leakage between the environments - right.
14:24:42 <lmcdasm> the ticket to have the cable pulled and firewall activated for the public repo was sent this morning (sorry i was slow on getting that).
14:24:48 <lmcdasm> no L2 leakage at all
14:25:12 <[1]JonasB> So we will have both ESXI and KVE envs.
14:25:17 <lmcdasm> each blade is given 1500 VLans to play with (for tenantes) and then another 100 for the vrouter to DMX (inter nested pod communication)
14:25:22 <lmcdasm> correct
14:25:45 <lmcdasm> basically im gonna tank input from Sberg and Msklaski on how they want their ubu and centos underOS setup
14:25:56 <[1]JonasB> Sounds great, and Blade 15 will be for repo mirror.
14:26:00 <lmcdasm> 16
14:26:29 <lmcdasm> it will take another day to harden up the switch config.. in the nested environments i have disabled LACP for now - we can turn it on at will between the blades
14:26:34 <[1]JonasB> So 16 will both be mirror and build server?
14:26:41 <lmcdasm> so people should be able to get in there tomorrow and play
14:26:49 <lmcdasm> hmm.. ok . i thought that blade 1 was jenkins
14:27:03 <lmcdasm> and then in each environment, people can make a "build vm" however they want
14:27:22 <lmcdasm> cause there is a "lot" of hardware for build servers.. but if you want a baremetal build server, we can allocate it - no sweat.
14:27:32 <[1]JonasB> Yes 1 is currently build, but the disk is to small. Fathi needs more mussels
14:27:37 <lmcdasm> ok.
14:27:47 <lmcdasm> Fatih.. tell me what you would like reqs wise in a email
14:27:50 <lmcdasm> and ill setup you up
14:27:51 <[1]JonasB> But lets use 16 for both.
14:27:53 <lmcdasm> err. set*
14:27:54 <lmcdasm> ok..
14:27:57 <lmcdasm> hmm.
14:28:05 <lmcdasm> actually no.. cause 16 will be cordned off
14:28:12 <lmcdasm> cause of the cable to the internet FW in our place
14:28:31 <lmcdasm> so.. i will discuss with the sudos about the access requirements to push things for the public to pull
14:28:47 <lmcdasm> we will use a different blade and make a nice big build VM that can be FT/HA
14:28:57 <lmcdasm> ill sort it with Fatih and we will come up with something?
14:29:05 <[1]JonasB> Public will not have to pull. The buildserver will push only.
14:29:25 <lmcdasm> yes.. but you wont be able to "get into it"
14:29:42 <lmcdasm> only to push files .. not to do command line interaction on the server from the outside world (not allowed)
14:29:54 <[1]JonasB> You can jump from blade 1 to blade 16 right?
14:29:56 <lmcdasm> no
14:30:02 <lmcdasm> no bridging allowed
14:30:33 <lmcdasm> sudos (you, me, stefan) will have console access and can when needed do maintainance, but the fileserver and webserver will be setup with access that way to push/pull files
14:31:19 <lmcdasm> from a web interface perhaps - but ITTE was pretty specific about no ssh into the cmd line and no bridging of this blade (since we are occupying the ericsson public C address space
14:31:32 <[1]JonasB> Ok, can you figure this out with Fatih today?
14:31:36 <lmcdasm> sure..
14:32:33 <[1]JonasB> #info set up of nested env (blade 9-15) with fronting soft routers ongoing, probably ready by tomorrow.
14:33:20 <[1]JonasB> #info will be followed up by setup of blade 2-8 for bare metal provisioning.
14:34:03 <[1]JonasB> #action Daniel to coordinate with Fatih on a new buildserver with more storage.
14:34:18 <[1]JonasB> Should we go to deploy?
14:34:35 <[1]JonasB> #topic Autodeploy
14:34:36 <lmcdasm> i dont have anything else to add in lab
14:34:57 <[1]JonasB> Szilard, fill in:-)
14:35:00 <Szilard> okay
14:35:32 <Szilard> This weekend I pushed some code that allows to handle the HP Blades
14:36:05 <Szilard> so now I am able to poweron, poweroff, change the boot order, get the mac address of the blades
14:36:26 <[1]JonasB> szilard: That is good news.
14:36:44 <Szilard> today I continue to work on the network configuration of the Fuel deployment
14:36:52 <[1]JonasB> Szilard: I will review it.
14:37:27 <[1]JonasB> Stefan is working on the KVM track.
14:37:30 <Szilard> I am studying the network yaml files, and how to modify them according to the Network topology and addressing logic that has been agreed with BGS
14:37:37 <Szilard> Peter Bandzi and others
14:37:52 <[1]JonasB> Szilard: Good
14:38:10 <lmcdasm> i have a workable proto type to connect, define VM, network, vlan and NIC and power on and boot fuel ISO
14:38:12 <Szilard> well that's all I need to sync up with Stefan
14:38:26 <lmcdasm> as soon as the lab is completed i can show it / push it up
14:38:49 <[1]JonasB> lmcdasm: Good
14:38:55 <Szilard> you mean a script ?
14:39:00 <lmcdasm> ya.
14:39:02 <lmcdasm> as well
14:39:05 <Szilard> sounds great :)
14:39:09 <lmcdasm> we have a autodeployer that
14:39:18 <lmcdasm> we built for the CSCF a while back.. for openstack
14:39:21 <lmcdasm> Peter W and I built it.
14:39:23 <[1]JonasB> We should have as the goal to have jenkins deploy fuel in a nested env.
14:39:28 <Szilard> aha, good to know
14:39:45 <lmcdasm> so i will send that along when i get my copy of it back (new laptop lost)
14:39:52 <Szilard> thanks
14:40:08 <lmcdasm> #question
14:40:23 <[1]JonasB> Shoot
14:40:55 <mskalski> I can also contact our mirantis CI/CD team and ask them what scripts they use to deploy fuel
14:41:00 <lmcdasm> since we will be deploying VM's and such should we be looking to using ETSI/OVF standard for describing the VM's or can we supply images (for compute and control, they are basically empty, but its a lot more XML if we can to be strict)
14:41:17 <lmcdasm> great mskalski!
14:41:26 <[1]JonasB> lmcdasm: R2
14:41:30 <lmcdasm> ok
14:41:41 <[1]JonasB> #info goal for this week is to have jenkins deploy fuel nested.
14:42:00 <lmcdasm> ack
14:42:06 <Szilard> got it :)
14:44:28 <[1]JonasB> mskalski: In your build that doesnt install. Could you compare the ubuntu-versions.yamlfile from the built std fuel iso and the resulting opnfv iso. The opnfv build re-generates that one so there might be a hickup in that logic.
14:44:53 <mskalski> [1]JonasB: ok will do
14:45:09 <[1]JonasB> Anything more for today?
14:46:00 <Szilard> nothing else from my side
14:46:02 <[1]JonasB> If not, lets talk again tomorrow.
14:46:09 <Szilard> good
14:46:18 <[1]JonasB> #endmeeting