16:01:34 <frankbrockners> #startmeeting BGS team meeting
16:01:34 <collabot> Meeting started Tue Apr 21 16:01:34 2015 UTC.  The chair is frankbrockners. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:34 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:34 <collabot> The meeting name has been set to 'bgs_team_meeting'
16:01:37 <ChrisPriceAB> Sorry delayed in ending
16:01:43 <lmcdasm> #info daniel
16:01:50 <frankbrockners> #info Frank Brockners
16:01:54 <ChrisPriceAB> #info Chris Price (needs to leave for 10 minutes, will be back)
16:01:59 <lmcdasm> #info daniel smith*
16:02:07 <HKirksey> #info Heather Kirksey
16:02:09 <[1]JonasB> #info Daniel Smith
16:02:12 <fdegir> #info Fatih Degirmenci
16:02:22 <[1]JonasB> shit Im not Daniel ?
16:02:27 <[1]JonasB> #info Jonas Bjurel
16:02:34 <[1]JonasB> Guess Im tire
16:02:44 * frankbrockners split personality?
16:03:02 <rprakash> #info rprakash
16:03:14 <[1]JonasB> Typinfg what I see on the screen, not mor brain works than that:-)
16:04:13 <radez> #info Dan Radez
16:05:48 <frankbrockners> #info per our discussion - let's do a quick check in on where we are - and what changed from yesterday to today
16:05:56 <frankbrockners> #info plan is to also update https://wiki.opnfv.org/get_started/get_started_release_plan#arno_release_readiness_-_status_summary
16:06:11 <trozet> #info Tim Rozet
16:06:41 <lmcdasm> so you want to go through the sheet line by line or how do you want to do this?
16:07:29 <frankbrockners> prior to jumping there - let's briefly chat about the TSC call
16:07:53 <frankbrockners> basic statement in the TSC is: they desire a plan to move to Rel. #1
16:07:54 <bryan_att> #info Bryan Sulivan
16:08:35 <frankbrockners> what I mentioned was: target release date could be "deploy.sh" working manually on LF hardware + 7 days.
16:08:50 <lmcdasm> sorry - im lost between the two statemnts
16:08:52 <frankbrockners> does this sound feasible?
16:08:54 <lmcdasm> review of TSC call
16:09:04 <ChrisPriceAB> yes, as long as we have a reasonably compete plan showing the 7 days is OK :)
16:09:08 <lmcdasm> or the "target relase date could be deploy.sh working manually on LF = 7 days
16:09:16 <[1]JonasB> #info what is ment by "manually"
16:09:31 <lmcdasm> as well - a deploy.sh working on LF hardware for what POD,
16:09:34 <lmcdasm> what build?
16:10:02 <[1]JonasB> lmcdasm: I guess both?
16:10:18 <frankbrockners> "deploy.sh" started by hand on a particular POD (1 for fuel, 2 for foreman) and installing things successfully
16:10:29 <lmcdasm> ok.. define successfully please?
16:10:40 <lmcdasm> what is the metric / test case we use for acceptance
16:10:53 <lmcdasm> since a "deploy.sh" can be many things - deploying the FOREMAN/FUEL VM
16:10:59 <lmcdasm> to getting the ODL up and using the GUI
16:11:23 <lmcdasm> and many things in between - and these are all install activities - they dont actually test the release or its content
16:11:25 <[1]JonasB> Do we have the test suite defined?
16:11:39 <frankbrockners> functest was not at the TSC call
16:11:48 <lmcdasm> so im a bit confused as to how an installation (without a testsuite) on "generic" hw( since we dont wanna dfined HW) is gating for the release?
16:12:26 <frankbrockners> successful for me would be: I can bring up two instances of a Linux VM and those two would ping each other. This is what functest calls vping.
16:12:36 <[1]JonasB> So there is a serious difference between having "deploy.sh" returning 0 and have a functional stack!
16:12:41 <lmcdasm> ok - and in that case then in LF it will fali (sice you dont have networks defined0
16:12:48 <radez> frankbrockners: vms in openstack?
16:12:53 <lmcdasm> and people wont be able to use the LF hw in the current network setup
16:13:08 <lmcdasm> (no routes to ge in  and around) that i ahve seen (Horizon), etc.
16:13:24 <lmcdasm> #JonasB - agreed. this needs to be clear and defined
16:13:37 <frankbrockners> LF lab will not be open to "people" - it will just be open to Jenkins
16:13:58 <frankbrockners> so ultimately it would be Jenkins to start the test suites.
16:14:10 <frankbrockners> but we're not there yet
16:14:57 <frankbrockners> so let's define the stages for "successful run of deploy.sh"
16:14:58 <lmcdasm> ok - so if Jenkins doesnt have the test suite
16:15:13 <lmcdasm> and the deploy.sh for each side is different (fundamentaly)
16:15:25 <frankbrockners> per Jonas: Success(1) could be "deploy.sh" returns (true)
16:15:32 <lmcdasm> Well thats easy then
16:15:37 <lmcdasm> we declare success today
16:15:45 <bryan_att> hooray!
16:15:46 <lmcdasm> cause a deploy.sh doesnt tell us anything "real"
16:16:04 <frankbrockners> yes - assuming that you at least try to install ostack, odl etc.
16:16:06 <lmcdasm> it just says "run script axy" and if that comes back (without any tesing in Jenkins) then you just know the script ran
16:16:12 <lmcdasm> well.. thats the issue
16:16:20 <trozet> lmcdasm: so you are saying that we just make up a return value and commit that as deploy.sh?
16:16:21 <lmcdasm> no more asssumptions .. tell me straight
16:16:22 <trozet> nobody is going to do that
16:16:29 <trozet> lets assume people are trying to actually complete the project
16:16:32 <lmcdasm> what do we want to say is "working" for this release
16:16:32 <trozet> and not trying to return 0
16:16:58 <lmcdasm> fair enough - but again, the point is that a deploy.sh =true is not the end, and leaves too much vagueness.
16:17:05 <trozet> the goal of deploy.sh is to deploy a functioning openstack HA environment with ODL as the neutron driver
16:17:09 <[1]JonasB> Of course there is a check that it appears to be deployed, but it really doesnt tell for sure
16:17:09 <lmcdasm> i would think at the end of our release we say " we have a Build that does XYZ"
16:17:14 <trozet> if it returns 0 it means that has happened
16:17:20 <trozet> our deploy.sh checks to make sure it is installed
16:17:22 <trozet> before it returns
16:17:25 <trozet> on every node
16:17:38 <lmcdasm> deployed != working
16:17:41 <trozet> at that point it is ready for tempest to run or whatever other framework
16:17:44 <trozet> puppet ensures its working
16:17:48 <lmcdasm> making sure its installed != working
16:17:49 <lmcdasm> how?
16:18:01 <HKirksey> Perhaps we could let trozet continue his list
16:18:01 <trozet> pacemaker resources will be in failed state
16:18:07 <trozet> if its not working
16:18:18 <HKirksey> And if at the end of his suggested steps we don’t think it’s sufficient then we could start adding
16:19:27 <trozet> that was kind of end of my list :)
16:19:31 <lmcdasm> well.. taking what Frank said " the test is a VM to VM communication from within a Deployed Openstack from FOERMAN/FUEL with ODL running" im not sure how Puppet will do this - but if the quorom is fine with that - saying deploy.sh is acceptable without any real tests - then fine -
16:19:31 <HKirksey> Ah ok
16:19:32 <HKirksey> :)
16:19:39 <trozet> openstack HA +ODL fully installed ready to have tempest executed
16:19:46 <trozet> thats what we have now
16:19:51 <trozet> I can kick off tempest right after it
16:19:53 <lmcdasm> as do we
16:19:54 <trozet> and get test results
16:20:03 <frankbrockners> can we define this as success(1)?
16:20:03 <lmcdasm> but thats not the question i believe
16:20:05 <HKirksey> and then tempest executes teh basic tests than functest has defined?  Which mainly net out to a ping?
16:20:13 <lmcdasm> the question is that we are looking to undestand what is a "PASS" for your release
16:20:17 <lmcdasm> and how to define it -
16:20:22 <frankbrockners> and then success(2) would be to have a set of functest defined scenario tests completed
16:20:29 <lmcdasm> so now we are saying Deploy + tempest?
16:20:50 <trozet> no I'm just saying the system state is ready at that point
16:21:04 <frankbrockners> it is probably deploy + tempest + robot (robot for the ODL piece)
16:21:05 <lmcdasm> do we have a framework / example for deploy.sh (since they two are differnet) or is each group just saying "yup - it worked" (going to the 3rd party questino).
16:21:19 <lmcdasm> so.. sorry if I find this funny
16:21:37 <trozet> deploy.sh, deploys the install/jumphost automatically and then provisions OpenStack HA+ ODL to baremetal
16:21:38 <lmcdasm> we were ready to try to declare release this week, but in 10 minuts we have expanded the criteria 3X?
16:22:16 <trozet> lmcdasm: that has been the agreed criteria for weeks we had meetings about this
16:22:21 <frankbrockners> Daniel - what would you suggest as criteria to define the different steps for success?
16:23:00 <lmcdasm> i would suggest the following:
16:23:19 <lmcdasm> test 1 - Jenkins is able to communicate and push artifacts to HW
16:23:30 <lmcdasm> test 2 - Deploy.sh is executed  and works
16:24:00 <lmcdasm> test 3 - Manually someone connects to the system, performs basic OPenstack operatoins (create/delete/use Horizon, test ceph), etc
16:24:10 <lmcdasm> thats it
16:24:12 <trozet> works -> deploys the install/jumphost automatically and then provisions OpenStack HA+ ODL to baremetal
16:24:23 <lmcdasm> works = that you are able to execute step 3
16:24:27 <radez> how is that different than openstack + odl ready for tempest?
16:24:28 <lmcdasm> cause if spte 2 failed you cantn do 3
16:24:38 <bryan_att> works for me - what are the roadblocks that we can help with?
16:24:38 <lmcdasm> well.. its a question f time and automation
16:24:52 <lmcdasm> so are we going to add more work (chris said we are frozen now)
16:25:23 <lmcdasm> and tempest cases would be run in step 3 (at lest in Fuel - they are embedded in the FUEL node to run)
16:25:32 <radez> not run tempest
16:25:35 <radez> just ready for it
16:25:38 <lmcdasm> so if i get it correctly, for FOREMAN, there would still be integration work.
16:25:41 <rprakash> 3 step process looks good me Daniel
16:25:48 <lmcdasm> so - how to we meausre and say that for a relaser Dan?
16:26:01 <lmcdasm> we say " we releaes R1 with Tempest Readiniss" thats not a testable / reportable ohject
16:26:23 <lmcdasm> so im confused how we report anything other than "its there" - which again, back to the start of this disucssion
16:26:34 <frankbrockners> wait - the tempest piece is something that the Functest team owns
16:26:49 <lmcdasm> im still fuzzy on why - if we havent said which HW, which Networking Equpment to use, etc - why this LF setup is gating at all - we have two pods ITEL/ERICSON and its all working on there
16:26:56 <rprakash> tempest is it included as partof deploy.sh?
16:27:02 <frankbrockners> so I'm fine with the above 1...3 + plus documentation
16:27:02 <bryan_att> can you say that you are tempest-ready without verifying that? and how much effort beyond that is automation?
16:27:14 <lmcdasm> why not simply have a 3rd party  - login to each POD and verify that each of us is telling the truyth / run an acceptance test procedure.
16:27:19 <trozet> lmcdasm: there should be verification in an installer to verified it installed correctly.. you shouldn't have to rely on tempest
16:27:32 <bryan_att> the 3rd party could be the functest team
16:27:46 <lmcdasm> ok
16:27:50 <frankbrockners> yes - per Bryan - the functest team is this 3rd pary
16:27:51 <frankbrockners> party
16:28:09 <rprakash> Yes  agreed atleat two people must have independently verifies that 3rd step manually and certify that
16:28:11 <lmcdasm> hmm. ok - so the functest started on POD2 yesterday?
16:28:22 <frankbrockners> so for now - can we agree that "success" means the 3 steps above, i.e.
16:28:22 <lmcdasm> anyway - are we agreed on common openstack feature set?>
16:28:29 <lmcdasm> not yet frank
16:28:37 <lmcdasm> we need more details of what is in those stetps
16:28:39 <frankbrockners> #info (1)  Jenkins is able to communicate and push artifacts to HW
16:29:09 <frankbrockners> #info (2) Deploy.sh is executed  and deploys the install/jumphost automatically and then provisions OpenStack HA+ ODL to baremetal
16:29:28 <frankbrockners> #info (3)  Manually someone can connect to the system, performs basic OPenstack operatoins (create/delete/use Horizon, test ceph), etc
16:29:36 <lmcdasm> ok.. well.. then just go ahead and we wont summarize what is to be in Step 2
16:30:18 <rprakash> Are we meaning Jenkins master from LF to Jenskins slave in respective labs for Fuel & Foreman in 1?
16:30:19 <lmcdasm> and for Step 3 - lets be clear on the tests (For both sides) cause for examplep 0- i dont knwo from Foreman what tests you run in tempest - we hgave provided the test layout from FUEL (but its like 600+ cases)
16:30:43 <lmcdasm> so we should resolve how to resolve delta in the testing sides (or come up with common test)  this is an important baseline to set
16:30:45 <frankbrockners> Daniel - we need to get this info from functest
16:30:49 <lmcdasm> ok
16:30:50 <frankbrockners> we don't have it for now
16:30:53 <lmcdasm> but then three is a problem
16:30:56 <fdegir> rprakash: OPNF jenkins master -> LF POD1 & POD2
16:31:04 <lmcdasm> since as i stated, the test we run is from the FUEL GUI
16:31:10 <frankbrockners> yes - but let's try to get to (2) first
16:31:16 <lmcdasm> so i think we are talking about two diffenet sets of test cases
16:31:44 <frankbrockners> (2) is what was meant by "Manual deploy to LF Hardware fully functional" on  https://wiki.opnfv.org/get_started/get_started_release_plan#arno_release_readiness_-_status_summary
16:32:38 <frankbrockners> in order to make some progress here - can we do a quick update on progress since yesterday? HW config issues, deploy status, updates to the table?
16:33:06 <frankbrockners> anyone who'd like to go first Daniel/Jonas/Tim/Dan?
16:33:18 <trozet> I can go
16:33:19 <lmcdasm> #question - the page shows that the ISO for FOREMAN was tested on POD2 - i logged in (cusae i was curious) and i dont see any SW (vagrant only) on the JS Pon POD2 and KVM is not installed so im puzzled as to this sheet,, so if you want to go ahead ok - but we will end up with two different variants o openstack installed
16:33:44 <trozet> huh
16:33:54 <lmcdasm> i would like to agree that we are all installing the same features in openstack (CEPH For glance and Cinder, etc)
16:33:57 <lmcdasm> before moving on
16:34:04 <lmcdasm> so that when we get to testsing we are testing "similar" setups
16:34:21 <frankbrockners> trozet: Could you just #info the current status - then we can discuss details?
16:34:27 <[1]JonasB> lmcdasm: +1
16:34:28 <lmcdasm> we all "know" generally what we are doing - but lets confirm we are configuring and installing the same openstack features / functions
16:35:18 <lmcdasm> or go ahead with your update Tim and we will go it later
16:35:35 <bryan_att> yes I hope we at least have consensus on that! (which features in OpenStack and ODL are installed - the "end state")
16:35:49 <frankbrockners> target system state is what we agreed a while back: https://wiki.opnfv.org/get_started/get_started_system_state
16:36:14 <frankbrockners> if there are additional deltas - let's discuss them and get them added to the wiki
16:36:31 <lmcdasm> ok - so no ceilometer no sahara no telemetry, no ceph?
16:36:46 <lmcdasm> anbd that diagram doesnt really match the topology agree and submitted - but sure.. lets go ahead
16:37:10 <bryan_att> With the exception that the BGS page is still fuzzy re "e.g. Possibility to drop from first release" - if someone could clarify without taking their eye off the ball it would be great!
16:37:44 <bryan_att> e.g. Horizon is shown as possibly dropped
16:37:49 <lmcdasm> cause if we dont have a common openstack feature set (not listed on the page)- then how will you know what tests failed for real or cause the feature wasnt there.
16:37:58 <ijw_> lmcdasm: Ceph at least is more a question of how you endable a feature and not the feature you're enabling; Sahara is an odd request; but point taken
16:38:16 <bryan_att> Just send me a list and I will update the page
16:38:36 <lmcdasm> well - im speaking in general ause thee is no deinition.. so for exaple, tempest has CEPH cases and non CEPH cases for cinder -
16:38:41 <trozet> #info Foreman status on LF: 1) Waiting for IPMI, mac info requested 2) Hitting a networking problem on the jumphost where ARP replies are not being passed from host to Vagrant VM.  Debugging this now.  We may try switching from VBOX to libvirt to see if that fixes the problem.
16:38:48 <lmcdasm> so if one team does ceph and the other not - our tests will be differnet.
16:39:29 <lmcdasm> #info tim - there is a problme with PXE and the UCS abstrction- i hit it last night looking around the web - seems we need to do somethign on the IFC to allow PXE port 67 to pass
16:39:36 <lmcdasm> (strange since its not a FW - but thats the best i got)
16:40:46 <frankbrockners> trozet: on 1) - who are you getting the info from?
16:41:00 <trozet> I requested it last week from Peter
16:41:56 <frankbrockners> ok - will see whether we can get that to you asap.
16:42:14 <frankbrockners> can someone summarize the Fuel status? Daniel, Jonas?
16:42:17 <lmcdasm> #info - same request for POD1 was sent
16:42:47 <lmcdasm> #info - POD1 stalled - networking not in place, no L3 architecture available, additionally (From colin today)
16:43:08 <lmcdasm> #info you will need an additional server to do tracining (setup port mirroring) in that setup (LF hardsware)
16:43:15 <[1]JonasB> #info We need to get started with testing autodeploy scripts - we're doing that in paralell on the Eri Lab
16:43:44 <lmcdasm> #info - Server1 still showing 4 NICS (should be two).  and the networking issues Tim mentioned are also present (suspect the IFC's VLAN tagging magic that Cisco HW does is the culprit).
16:44:20 <lmcdasm> #info - HA baremetal on Eri LAb started - 6 node configuration - waiting to confirm (here) what the feature set is (or we go with the Eircsson standard deploy if we dont have a consensus).
16:44:27 <lmcdasm> #info - thats it for me
16:44:59 <[1]JonasB> #info from me too
16:46:17 <[1]JonasB> #info When can we get lawyer feedback on the LICENCE.rst file?
16:46:18 <frankbrockners> [1]JonasB: Any blocking issues? Or better: Did you make progress post the earlier synch meeting you had with Peter?
16:46:35 <[1]JonasB> #info Working on it.
16:46:58 <frankbrockners> #info Whether server 1 shows 2 or 4 Nics should not be an issue - you could ignore the two superfluous ones.
16:47:06 <lmcdasm> #info no
16:47:15 <lmcdasm> no thats not true frank - what makes you say that?
16:47:24 <lmcdasm> since its very dependant and as i asked
16:47:46 <lmcdasm> the VLANs that are tagged for NIC2 (that will boot the rest of the servers) has to be confirmed on which ENP they will boot
16:48:03 <rprakash> If we have 5 nics why can't we get Fuel nic seperated out from 4 of Foreman , that may save all these issues
16:48:07 <lmcdasm> as discussed, if NIC2 is the NIC on the JS server to do PXE - what is the NIC on the rest of th eservers that will receive this
16:48:14 <lmcdasm> is it enm6 or 9 or?
16:48:22 <lmcdasm> ]cause then the boot order of the NICs will have to be changed to match int he code
16:48:28 <frankbrockners> we can have as many NICs as you want
16:48:31 <lmcdasm> better to simply conigured it as requstes
16:48:40 <lmcdasm> Frank - the issue is NOT nics
16:48:52 <lmcdasm> its their tagged in th e switch and which nic to which for jumpstarting
16:48:55 <frankbrockners> to make things simple: We'll remove the two superfluous NICs for now
16:49:05 <lmcdasm> thts doesnt address my issue / or question frank
16:49:42 <lmcdasm> removing to two nics still doesnt answer the qustion of the VLAN setup
16:49:48 <frankbrockners> the two NICs you get won't get tagging in the switch - I believe things are already configured that way
16:49:51 <lmcdasm> so are you doing enpX to enpX on the rest
16:50:03 <lmcdasm> ok - thats not the issue
16:50:10 <rprakash> trunl only 1 nic for vlans and give it to Fuel, rest NIC0 is common and no tagging so he other 4 for Fuel
16:50:14 <lmcdasm> perhaps a phone call to explain is bette
16:50:18 <lmcdasm> well. that not the question
16:50:22 <rprakash> Foramn I mean 4
16:50:26 <lmcdasm> ?
16:50:42 <[1]JonasB> What about the LICENCE
16:51:10 <[1]JonasB> It was suposed to be there last Friday, is the content OK?
16:51:32 <lmcdasm> if you have a Server with 2 nics,.. and FUEL is setup on NIC2 to send out all the OPNESATCK stuff .. then can you please confirm on the rest of the server that their first BOOTABLE NIC is in the same vlan groups as the ones that are tagged to NIC2 on the JS Server?
16:51:47 <lmcdasm> that is the qustino -0 othewise when FUEL sends out packest - what NIC on the rest of the servers to they arrive at?
16:52:07 <lmcdasm> cause you have enp9 across everything so does that mean we change to make all th eservers boot from enp9 or ?
16:52:17 <bryan_att> Jonas, link the license file here and I will ensure the legal team responds to a request for review.
16:52:17 <lmcdasm> does that explain the question better?
16:52:41 <[1]JonasB> How do I link to git?
16:52:48 <frankbrockners> Daniel - per what I understood from Peter, things are already configure that way for POD1
16:52:54 <lmcdasm> they are not
16:53:05 <lmcdasm> and sa i said, sinc eyou dont have any L3 setup - you dont have a wway to verify
16:53:13 <bryan_att> OK, which project and folder/path - I will find it
16:53:18 <lmcdasm> hence the comment from Colin about setting up a wireshark / tracer
16:53:21 <fdegir> [1]JonasB: is it still under review?
16:53:34 <lmcdasm> cause right now - if I boot JS and Serve 2- i dont know what NIC on SERVER2 i shold expect packets to come in on
16:53:41 <[1]JonasB> bryan_att: /fuel/LICENCE.rst
16:53:49 <frankbrockners> Daniel - we discussed all that with Jonas earlier today
16:53:59 <lmcdasm> and if its ENP9 then we need to do a code chagne / still need the MAC/IPMI infor that we (tim and I) requested last friday
16:54:00 <fdegir> if it's not merged yet
16:54:04 <rprakash> #link https://wiki.opnfv.org/get_started/lflab_hosting
16:54:05 <fdegir> it won't be there
16:54:21 <[1]JonasB> Can we take this separately please
16:54:39 <lmcdasm> that digram is not accurate
16:54:55 <fdegir> https://gerrit.opnfv.org/gerrit/#/c/358/3/fuel/LICENSE.rst
16:54:56 <lmcdasm> anyway - seems that we dont want to discuss the hard pionts here
16:55:10 <frankbrockners> Daniel - well confirm the interface name
16:56:59 <bryan_att> Jonas, please send an email to take this offline - there doesn't seem to be a .RST license file in that link/folder https://git.opnfv.org/cgit/genesis/tree/fuel/LICENCE
16:57:28 <fdegir> bryan_att & [1]JonasB: since it's still under review on gerrit
16:57:29 <rprakash> Did we not agree that licnses will be all apache 2.0 fro upstream?
16:57:33 <bryan_att> ok sory
16:58:06 <fdegir> [1]JonasB: Is this the one you're referring to -> https://gerrit.opnfv.org/gerrit/#/c/358/3/fuel/LICENSE.rst
16:59:55 <frankbrockners> we're at the top of the hr... - so I'll get back on interface naming and ILMI info
17:00:06 <frankbrockners> can we do another synch tomorrow - same time?
17:00:14 <rprakash> Ok
17:00:20 <lmcdasm> can we finsih the discussion about install state?
17:00:26 <lmcdasm> or do we just do out thing?
17:00:33 <frankbrockners> I'll set something up - just in case
17:00:49 <lmcdasm> fine
17:01:24 <frankbrockners> Daniel - could you compile a proposal that we can add to the wiki: https://wiki.opnfv.org/get_started/get_started_system_state?
17:01:27 <rprakash> is this current diagram?  #link https://etherpad.opnfv.org/p/diagram
17:01:48 <frankbrockners> ok - thanks everyone for now.
17:02:07 <frankbrockners> see you again the latest at 9am PDT tomorrow on this channel
17:02:11 <frankbrockners> #endmeeting