16:00:09 <frankbrockners> #startmeeting BGS daily Arno release readiness check in
16:00:09 <collabot> Meeting started Wed Apr 29 16:00:09 2015 UTC.  The chair is frankbrockners. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:09 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:09 <collabot> The meeting name has been set to 'bgs_daily_arno_release_readiness_check_in'
16:00:16 <frankbrockners> #info Frank Brockners
16:00:40 <trozet> #info Tim Rozet
16:01:13 <fdegir> #info Fatih Degirmenci
16:01:21 <pbandzi> #info Peter Bandzi
16:01:28 <[1]JonasB> #info Jonas Bjurel
16:01:42 <HKirksey> #info Heather Kirksey
16:02:43 <frankbrockners> #info Agenda is our typical one: Roundtable on progress being made - different deployment tools and LF HW
16:03:43 <frankbrockners> Peter - could you give us a quick update on the "frames tagged received with VLAN 0" situation - as well as any other LF HW updates?
16:03:55 <radez> #info Dan Radez
16:04:02 <pbandzi> yes
16:04:04 <frankbrockners> #info Topic: Update on the "frames tagged received with VLAN 0" situation - as well as any other LF HW updates?
16:04:15 <frankbrockners> thanks Peter - go ahead
16:04:21 <morgan_orange> #info morgan
16:04:25 <pbandzi> #info if native vlan is configured on FI, it strips the vlan tag, not to priority bits. priority bits should be preserved. So it sends the packet with vlan0. This is correct.
16:05:32 <pbandzi> #info i did quick check on enic module on jumphost and saw there is not the latest available version of enic driver
16:06:12 <frankbrockners> #info are you planning to update the driver?
16:06:39 <pbandzi> #info according matrix http://www.cisco.com/web/techdoc/ucs/interoperability/matrix/matrix.html
16:06:50 <pbandzi> #info we can try to upload latest driver
16:07:15 <frankbrockners> #info When can we do the update?
16:07:32 <pbandzi> i can do it tomorrow morning ~9am
16:07:35 <pbandzi> CET
16:08:09 <frankbrockners> Would tomorrow (Apr/30) - 9am-10am CET == 12am-1am PDT work for everyone?
16:08:41 <frankbrockners> trozet morgan_orange: r u ok with that window?
16:09:30 <morgan_orange> for the moment I wait for grene light so no problem for me (successfully connected on jumphost today, I saw that rally and robot were already installed)
16:09:41 <frankbrockners> trozet: ok?
16:10:12 <frankbrockners> radez: ok?
16:10:48 <radez> yup that's good for us
16:10:53 <frankbrockners> thanks
16:11:18 <frankbrockners> #info driver update will be done in a maintenance window tomorrow (Apr/30) - 9am-10am CET == 12am-1am PDT by pbandzi
16:12:11 <frankbrockners> #info For those who want to have some more background on this VLAN 0 priority tagging feature - here is some related documentation: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/atm/configuration/15-mt/atm-15-mt-book/atm-15-mt-book_chapter_011000.pdf
16:12:27 <frankbrockners> pbandzi: any additional updates on LF HW?
16:12:39 <pbandzi> that's all
16:12:45 <frankbrockners> thanks Peter
16:12:48 <frankbrockners> moving on
16:13:14 <frankbrockners> #info Topic: Update on deployment tools (Fuel, Foreman)
16:13:20 <[1]JonasB> #info We're done with all the logic/programming needed for auto deploy. Since we have a short week in Sweden/Europe we will start testing on Monday. After that we go to LF-lab.
16:13:59 <[1]JonasB> #info Due to public hollidays there will be little happening between now and Mon
16:14:23 <[1]JonasB> Thats all from me
16:14:25 <trozet> sorry I dc'ed
16:14:28 <frankbrockners> thanks Jonas
16:15:27 <radez> #info trozet has got OpenStack and ODL deploying successfully on POD2 via foreman
16:15:48 <radez> I'll let him comment further since he came back :)
16:16:34 <frankbrockners> radez: is the ISO fixed by now?
16:16:56 <radez> frankbrockners: I've got a patch in jenkins that I'm finshing up getting though the gate
16:17:01 <radez> should be done today
16:17:12 <frankbrockners> radez: could you #info that?
16:17:39 <radez> yes sry.
16:17:44 <frankbrockners> thanks
16:18:03 <radez> #info patch is in gerrit to fix the foreman iso https://gerrit.opnfv.org/gerrit/#/c/409/
16:18:13 <radez> #info should be ready for reviews today
16:18:26 <frankbrockners> trozet: how close are you to giving "green light" to morgan (for functest)
16:19:49 * frankbrockners looks like trozet bailed for a moment
16:20:06 <frankbrockners> let's briefly switch to functest -
16:20:17 <frankbrockners> #info Topic: Updates from Functest
16:20:30 <frankbrockners> morgan_orange: any quick updates from your end?
16:20:35 <morgan_orange> #info doc updated: http://artifacts.opnfv.org/functest/docs/functest.html
16:20:53 <morgan_orange> #info successfully connected to POD1 and POD2 jumphost
16:21:23 <morgan_orange> #on LF so wait for green light to start testing (would need creds for RC file) dunno if both installers have the same passowrd policy
16:21:41 <morgan_orange> #info vPing commited
16:22:31 <frankbrockners> on the password policy...
16:22:31 <morgan_orange> #info discussion initiated with Metaswitch for VIMS (collect network requirements)
16:23:21 <frankbrockners> originally we picked opnfv/opnfvstack as the "default" - that said, so far I saw opnfv/octopus used throughout. Is this still the case for both setups/PODs?
16:23:50 <frankbrockners> if this is the defacto standard then we can stay with it for now
16:24:16 <frankbrockners> [1]JonasB, trozet, radez - any thoughts?
16:24:41 <trozet> one sec
16:25:24 <radez> does bother me either way.
16:25:43 <radez> sry... doesn't bother me either way
16:26:35 <[1]JonasB> frankbrockners: What is the question?
16:26:55 <frankbrockners> [1]JonasB: originally we picked opnfv/opnfvstack as the "default" - that said, so far I saw opnfv/octopus used throughout. Is this still the case for both setups/PODs?
16:27:17 <frankbrockners> [1]JonasB: or in other terms - which username/pw do you use/expect?
16:27:57 <[1]JonasB> frankbrockners: We can do eiter way. Just decide and we accomodate
16:28:24 <frankbrockners> everyone ok if we are pragmatic and stay with opnfv/octopus?
16:29:11 <trozet> yeah the passwords can be set in our yaml file
16:29:19 <frankbrockners> if noone speaks up - I'll #agree that
16:29:26 <frankbrockners> ok
16:29:54 <trozet> i was just using what was in there, rather than the offiicial BGS
16:30:33 <frankbrockners> #agree default username/pw for CI will be opnfv/octopus (which is what is used today) - which changes the earlier agreement (which was opnfv/opnfvstack)
16:30:47 <frankbrockners> thanks Morgan for the functest update.
16:30:57 <frankbrockners> are there any other things we need to cover today?
16:31:07 <trozet> sorry I was disconnected earlier
16:31:27 <trozet> #info will handoff LF pod2 by end of day to morgan_orange and functest team
16:31:56 <HKirksey> That’s exciting, right?
16:32:20 <trozet> yeah!
16:32:21 <frankbrockners> great - good that we captured that. so morgan can start functesting first thing tomorrow morning - after peter is done with the upgrades
16:32:22 <morgan_orange> ok can start manuel test +CI tomorrow (public holidays on friday)
16:32:53 <morgan_orange> wait for 2 green lights then
16:35:37 <frankbrockners> ok - looks like we're done
16:36:01 <lmcdasm> one question pleas?
16:36:06 <frankbrockners> we can have a quick synch tomorrow - at least for those who can make it
16:36:12 <frankbrockners> sure Daniel - go ahead
16:37:20 <lmcdasm> have we all agreed that pulling 'live" from the internet to a the Jumpstart Host is the way we are going then?  I.e whenever you intall FOREMAN the requirement is internet access and we are always Pulling "latest" build?  - if so, can somone comment on how we will support this, have a static release into a ISO? and how that will work in carrier / operator networks where you will not be
16:37:20 <lmcdasm> able to do this?
16:38:49 <[1]JonasB> AS you now, Fuel will not do so, everything needed is on the iso.
16:39:22 <lmcdasm> ok.. so are we saying FUEL for carrier/DC's and FOREMAN For public deployments then ?
16:40:00 <[1]JonasB> lmcdasm: DOnt know, just a comment on Fuel
16:40:35 <lmcdasm> understood - im just trying to figure out when R1 is out - what the ISO will contain.. our FUEL stuff with all the "release" and then a FOREMAN setup that goes and fetches stuff?
16:41:04 <lmcdasm> just wondering how we will support this when people call and say "hey  - im deployming FORMEAN and i had a problem " and we say" ahh.. well. rebuild cause we fixed something in gerrit today?"
16:41:11 <frankbrockners> trozet, radez: are you always pulling "latest" or a specific version?
16:41:55 <trozet> depends on what you are talking about pulling
16:42:02 <trozet> we pull the latest centos7 released on the mirror
16:42:10 <lmcdasm> #trozet - to be more clear
16:42:39 <lmcdasm> im talking about the OPNFV release, that containes all the repos you need to build - basically if I understand currentl (and im might be wrong so correct me)
16:42:51 <lmcdasm> the FOREMAN stuff doesnt delivey any "content/binaries" at all
16:43:09 <lmcdasm> it has a collection of script that pulls CEntos, Openbstack ,etc from upstream libs
16:43:12 <lmcdasm> and then installs them on the fly
16:43:21 <trozet> yeah
16:43:28 <lmcdasm> alright
16:43:41 <lmcdasm> so.. then.. how do we control this.. how do we say "this is what is done for R1"
16:43:49 <lmcdasm> and how do we align testing to match
16:44:00 <lmcdasm> since each day (Potentiall) you are testing against a differetn "setup"
16:44:04 <lmcdasm> if things change up stream
16:44:33 <trozet> well most of the things we are installing are from EPEL7 or RDO
16:44:42 <lmcdasm> fair enough
16:45:10 <trozet> but there could be an issue like that
16:45:14 <lmcdasm> hence my qeustion - are we agreed that we are going to support anything that might change in EPEL /RDO ? and how do we say we have "testing" this (timestamp adn then forget it or?).
16:45:51 <lmcdasm> and secondly - except for developments, the assumption that you will be able to reach those repos (while we can make the requirements) is not realistic
16:45:59 <trozet> well it will be up to us in Octopus to debug and figure out if a package is updated and broken
16:46:10 <lmcdasm> ATT, VFE, etc - have a strict policy that there is no "upstream" / public access to their DCs
16:46:10 <trozet> we dont release a static product for R1
16:46:16 <trozet> we release a method to install
16:46:21 <lmcdasm> ok.. thx Tim
16:46:57 <lmcdasm> if that is the case and its agreed. then i dont have anything else to say on the matter - except that its going to be super hard to support and deploy in most DC cases
16:47:25 <trozet> hmm
16:47:34 <trozet> well if that becomes the case we can package it locally on the jumphost through our ISO
16:47:39 <trozet> then deploy from our jumphost
16:47:44 <lmcdasm> i would say that is the way to go
16:47:50 <lmcdasm> since then you have a "package" that is tested and released
16:48:01 <lmcdasm> otherwise each time you dont know what you are dealing with upstream
16:48:10 <lmcdasm> and then we end up chasing is it "our stuff" upstream, etc
16:48:24 <lmcdasm> and there is no way to reall say "yes, Functest works on this day with this package" (i.e release integrity)
16:48:36 <lmcdasm> again - its up to you / project really - not trying to say "you must do this"
16:48:45 <trozet> we will fix that when it comes to it.  In the meantime we are documenting all current packages on the wiki
16:48:47 <lmcdasm> just bringing it up as a course of how people will use it
16:48:50 <trozet> so we will know what we used at R1 relesae
16:49:09 <lmcdasm> fair enough - you just wont know what 'versoin" of those packages you are using (cause they may change at any time).
16:49:18 <lmcdasm> again - if im the only one who cares, then no worries
16:49:46 <frankbrockners> imho it is mostly about nailing the references you use for a "release"
16:50:10 <lmcdasm> agreed Frank and to add tying to to a Functest that says we verified it
16:50:23 <frankbrockners> makes sense
16:50:28 <fdegir> I also think this is important from CM/release management  point of view
16:50:55 <frankbrockners> yes - this is release vs. latest build
16:51:02 <lmcdasm> cause if its always "latest" then there is no way (without some coding madness) to match R1 release "objects" to a verified test, etc., etc
16:51:28 <frankbrockners> release should fix the references (or put things into a single basket like a versioned ISO)
16:51:41 <lmcdasm> so when we say we "tested" FOREMAN , we will need to note down the current state/ver of all the packages that were pulled for that specific deployment at that time
16:51:45 <frankbrockners> latest is latest which means "good luck"
16:51:57 <lmcdasm> ya.. and i think you can do both sure
16:52:00 <fdegir> and that is fine for development phase
16:52:07 <lmcdasm> but i think that having a "release" object for our release is needed.
16:52:07 <trozet> or the CI phase
16:52:08 <fdegir> up to certain level
16:52:17 <[1]JonasB> frankbrockners: I think it is mor than nail the references, it is about to relyably be able to reproduce a deployment.
16:53:01 <lmcdasm> maybe im oversimpifying, but at relaees time we say we have R1 that is tested with XYZ and here is the ISO that has all you need.. if we keep a hole open, then each test comes into question
16:53:04 <lmcdasm> imho
16:53:10 <frankbrockners> [1]JonasB: nail the references would include that you pull the "nailed" referenced RPM from upstream and not the latest
16:53:23 <trozet> lmcdasm: so when CI runs for Fuel, do you guys not pull the latest opendaylight helium on SR branch?
16:53:36 <[1]JonasB> frankbrockners: Then Im with you!
16:54:11 <lmcdasm> no
16:54:13 <lmcdasm> we dont.
16:54:15 <trozet> the point of octopus is to do CI testing, which would mean pulling latest builds
16:54:23 <lmcdasm> the buyild system generates an ISO
16:54:27 <trozet> at least of openstack/opendaylight
16:54:28 <lmcdasm> this is autodeployed to an set of hardware
16:54:37 <lmcdasm> all the Fetching is done and dumped into a ISO
16:54:47 <lmcdasm> thus we have a static/ traceable package that we put against CI
16:54:55 <fdegir> but that is "CI" and whenever we build something within CI, that something must be reproducable
16:55:05 <frankbrockners> hmmm... for CI I would have expected to use "latest"
16:55:22 <trozet> at least latest openstack +odl build for a version
16:55:22 <lmcdasm> well. each time you do a build and create a new ISO
16:55:27 <frankbrockners> for a "release" you pick a point in time
16:55:28 <fdegir> once you start the build, it is latest of our own code base with  known dependencies
16:55:32 <lmcdasm> then you have the Latest (or whatever the build system is pointing to)
16:55:45 <lmcdasm> so that each "run" is testing a complete package that is traceble
16:55:53 <[1]JonasB> Maybe a topic worth an own session?
16:55:56 <lmcdasm> so lets say i have build-X and we test it and its fine
16:56:08 <lmcdasm> then that is a Releae Candidate and we have and whole package
16:56:19 <frankbrockners> [1]JonasB: +1
16:56:20 <lmcdasm> then the next day you do another build
16:56:27 <lmcdasm> build-y - that would be with the latest
16:56:37 <lmcdasm> and agin, geneartes a complete package, is tested against with functest
16:56:40 <lmcdasm> and then can be considered for release
16:56:52 <lmcdasm> each day the artifacts have the "latest" build that people can fetch
16:57:05 <lmcdasm> but we arent talking about "latest" we are talking about having something we put up for consideration as a RC
16:57:18 <lmcdasm> and for that part you dont want "latest" cause you will chase you tail forever as things change
16:57:29 <[1]JonasB> So I need to leave, can we pick a time for this discussion?
16:57:30 <lmcdasm> you want something static that we can say " yes - we know tall the things in there and can outline them)
16:57:31 <frankbrockners> does anyone feel like he would want to pull together a wiki on "release", "latest build" etc. definitions - so that we can have a dedicated meeting on it and agree?
16:57:38 <lmcdasm> hmm.
16:57:44 <lmcdasm> i would say that is an AP on the TSC
16:57:52 <trozet> so you create a static release
16:57:55 <frankbrockners> yes - but TSC needs input...
16:57:56 <trozet> to test openstack and opendaylight
16:58:00 <lmcdasm> to outline what those mean and what you want in terms of a Releaee Candidate critera
16:58:14 <lmcdasm> well. i can summarize my thoughts in a mail and send it around if you like
16:58:25 <lmcdasm> we create a static release yes ttim
16:58:28 <frankbrockners> could you put things onto a wiki instead?
16:58:34 <[1]JonasB> That would nbe a good starting point!
16:58:35 <frankbrockners> that way people can add
16:58:38 <lmcdasm> cause then we know that we are testing "ODL YXZ with OPENSTACK XYZ, etc, etc"
16:58:55 <trozet> so then you certify that ODL works with openstack by BGS?
16:58:57 <lmcdasm> ok.. im a bit hesitatnt with wiki's cause there is no index an unless we spam the link , its hard to find
16:58:59 <trozet> that doesnt make any sense
16:59:06 <lmcdasm> ok. tim - which part?
16:59:07 <trozet> because htey dont work for R1
16:59:09 <[1]JonasB> Daniel: You and I work on a Wiki next week!
16:59:12 <trozet> so we wont make that happen anyway
16:59:12 <lmcdasm> maybe im not explaining well
16:59:23 <frankbrockners> thanks Daniel & Jonas!
16:59:29 <lmcdasm> if i understand - each time you build - you get the latest from ODL
16:59:38 <lmcdasm> what happens when they switch to Lithium
16:59:41 <trozet> latest helium
16:59:41 <frankbrockners> we can link the wiki off the main BGS page
16:59:51 <lmcdasm> then your system on a R1 release of ARNO is now doing something completly differnet no?
16:59:55 <frankbrockners> folks I really have to run...
17:00:06 <frankbrockners> I'm going to endmeeting... but feel free to continue the chat
17:00:08 <frankbrockners> #endmeeting