14:35:16 <greg__> #startmeeting OpNFV
14:35:16 <collabot`> Meeting started Tue May 10 14:35:16 2016 UTC.  The chair is greg__. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:35:16 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:35:16 <collabot`> The meeting name has been set to 'opnfv'
14:35:39 * s_berg is pressing the recycle button
14:35:42 <s_berg> #info Quick status update from my end: Updating the buildsystem for Fuel/Mitaka. No major snags, disabled plugins as we did before (to be re-enabled as they reverify), hope to have something to submit this week.
14:36:20 <greg__> good
14:36:48 <greg__> any estimates on the amount of time it will take to fully wrap it up
14:36:53 <DanSmithEricsson> #info daniel smith (tardy)
14:37:20 <SzilardCserey> #info Szilard Cserey
14:37:23 <joseppc> #info Josep Puigdemont
14:37:36 <z0d> #info Peter Barabas
14:37:38 <ehfci> #info Ferenc Cserepkei
14:37:41 <mskalski> #info opendaylight plugin rebased to 9.0, support for odl_v2 added, currently working on HA deployment of odl controllers, building the plugin require fpb from github
14:37:54 <greg__> #info Greg Elkinbard
14:38:02 <mskalski> #info Michal Skalski
14:38:08 <DanSmithEricsson> #info manual deploy of 9 to baremteal done
14:38:10 <z0d> #info I did a semi-automatic Fuel 9 install and it worked. I think I can uplift autodeployment in a couple of days after the build system is working
14:38:18 <DanSmithEricsson> #info ready to reap when uplight is available so we can setup CI / automation
14:38:28 <s_berg> Well, so far things has gone really smooth, but the mirroring process may bite us if it has been modified from 8.0. Will try to enlist the expertise of mskalski in that case, as before. :)
14:38:37 <DanSmithEricsson> #uplift*
14:39:25 <DanSmithEricsson> z0d - that is great stuff.. we should look to try it on baremetal next week following plugfest in the lab
14:39:29 <[1]JonasB> Hi
14:39:31 <s_berg> But keep in mind that z0d probably needs to do some magic for the deploy parts once we have an image, I would be surprised if everything works out of thebox.
14:39:32 <greg__> is Peter on the line
14:39:41 * z0d is Peter
14:39:42 <DanSmithEricsson> thats z0d -
14:39:43 <zhihui_wu> info Zhihui_Wu
14:39:48 <z0d> hi Jonas
14:40:04 <ehfci> hi Jonas
14:40:04 <greg__> Peter any updates on fuel deploy code
14:40:10 <s_berg> Sorry z0d, you just said so, missed that. :)
14:40:33 <z0d> I did a semi-automatic Fuel 9 install and it worked. I think I can uplift autodeployment in a couple of days after the build system is working
14:40:44 <greg__> k
14:40:51 <z0d> haven't found any showstoppers yet
14:41:04 <[1]JonasB> ZoD: Super.
14:41:13 <DanSmithEricsson> i found a bug if you change password from default
14:41:21 <DanSmithEricsson> but i will show ya when autodeploy is ready Peter
14:41:32 <z0d> all right
14:41:41 <[1]JonasB> Im coming with a commit to collect all logs and snapshots from a deploy, today or tomorrow.
14:41:43 <greg__> do we need to do anything for scenario
14:42:05 <DanSmithEricsson> we need to start to implement the BASELINE + NCX varabiles in the scnario files
14:42:18 <z0d> DanSmithEricsson: would you be so kind and merge the commits you've just reviewed? <-:
14:42:34 <DanSmithEricsson> as part of PHAROS intiative...all scenariso should have the variables for whate PHAROS HW topolog they care calling
14:42:43 <DanSmithEricsson> so we need to look to add some dataset in the scnearios.
14:42:58 <DanSmithEricsson> so we can have it when Pharos starts to read to in line wiht automated HW prep for deployment
14:44:03 <zhihui_wu> hi, Fuel team, I am engineer from ZTE. I am in charge of ZTE pod. Fuel is the installer on our pod. To achieve auto deployment with fuel , I have contributed the code about supporting bonding interfaces for HA. Could you please help to review https://gerrit.opnfv.org/gerrit/#/c/13679/.
14:44:44 <greg__> Jonas, Peter can you review pls
14:44:50 <ehfci> #DanSmithEricsson how much work adding BASELINE+NCX?
14:45:18 <DanSmithEricsson> it shouldnt be too much.. a couple of lines in the yaml would do it - probably two or three VARS at most
14:45:50 <DanSmithEricsson> that can be either sources or passed (.include, etc) when we parse the scenario for HW and Switch layout time (pre-deployment of JUMPHOST/FUEL/etc)
14:46:12 <zhihui_wu> Thanks to all
14:47:06 <DanSmithEricsson> basically similar to how we callplugins / features for deployment in openstack
14:47:37 <DanSmithEricsson> we are giong to have a function that changes the lab layout based on agreed lab topology types (that the Pharos community can support / has gone through the process)
14:47:59 <DanSmithEricsson> so that we can suppotr DPDK, SRIOV and the more complex types that are coming now that dont fit BASELINE (3 controller , 2 compute and a SDNC)
14:48:23 <[1]JonasB> zhihui_wu: I dont think you need this mod, it should be enough that yo do a manual deploy with bonding and reap the configuration for that.
14:48:47 <DanSmithEricsson> additional NIC, bonding, etc
14:50:11 <greg__> number of scenarios will get large
14:50:13 <DanSmithEricsson> would love to get some input from Peter, SBerg and JOnas about where this type of info should sit best - should it be in the scenario or someplace lower perhaps?  reaping can be expanded and used to capture more complex deployments / layouts?
14:50:29 <DanSmithEricsson> well.. scenarios will grow and shrink in line with demand for projects in a cycle
14:50:46 <DanSmithEricsson> there is a dicussion now about the "need" to carry everything all the time. and run all of them. dave McBride is on that
14:51:06 <greg__> for dpdk/sriov
14:51:14 <greg__> there is sriov only
14:51:18 <greg__> dpdk only
14:51:19 <DanSmithEricsson> but from a pharos / infra point of view, we need to have a method to make sure that whatever is propped up on the developer cycle can be used in the CI cycle - that there are labs and way to handle the changes from one to another
14:51:37 <greg__> both on the same node on sep interfaces
14:51:44 <DanSmithEricsson> Greg - im not speaking in specifics, they are all lined out on the pharos group .. im giving overview on a abstract
14:52:04 <DanSmithEricsson> and why we need this - there are lots of other areas, storage, wan and multisite confis we are going to template as well
14:52:10 <greg__> would it be better to have a generic hardware descriptor yaml
14:52:14 <DanSmithEricsson> im looking more for where in our model we should indicate such info
14:52:17 <[1]JonasB> DanielSmithEricsson: Not sure right now where it fits best.
14:52:25 <greg__> and code the scenarios into that yaml
14:52:33 <DanSmithEricsson> that is what we are working towards -greg..  ya. Jonas - im just getting interest. thought generation
14:52:42 <greg__> it is a bit more work
14:53:05 <DanSmithEricsson> well.. im not saying to start anything really.. casue it will be much more broad than just FUEL's scnearios
14:53:15 <DanSmithEricsson> and will be workied into the release cycle process and CI
14:53:37 <DanSmithEricsson> just saying.. its coming and to think about where we can indicate the PHAROS reference set you want in a given scenario
14:53:51 <DanSmithEricsson> if you find one that makes sense.. let us know - we can try one or two out and see in the coming weeks maybe
14:56:55 <greg__> do we know
14:57:04 <greg__> how much scenario work is required
14:57:09 <greg__> for the Colorado
15:01:42 <[1]JonasB> greg__: Do you mean on the scenarios as such or the scenario framework
15:01:47 * s_berg must run, see you guys later!
15:02:07 <z0d> s_berg: laters
15:02:40 <greg__> yes
15:03:20 <[1]JonasB> greg__: Yes to what :-)
15:03:33 <greg__> sorry multitask
15:03:52 <greg__> I am trying to understand the total scope of work required in scanrios for colorado
15:04:07 <greg__> and when is it like to complete
15:04:26 <[1]JonasB> Scenarios them self is written by the feature projects.
15:04:30 <zhihui_wu> JonasB, I think the bonded interfaces scenario is necessary. I have found a bug about odl with bonded interfaces: https://review.openstack.org/#/c/312586/
15:05:09 <[1]JonasB> We have a few improvements on the scenario framework which we want to do, not a tremendous amount of work.
15:05:29 <zhihui_wu> Our pod plan to run a different scenario with the other labs. So we deploy env with bonded interface.
15:05:41 <greg__> end of may?
15:06:07 <[1]JonasB> greg__: Zod should answer.
15:06:17 <greg__> k
15:06:17 <z0d> I'd say mid June
15:06:31 <zhihui_wu> If you think this need more discuss, our pod can deploy without bonded interfaces on jenkins job.
15:06:32 <z0d> we still need to decide on how to proceed
15:07:02 <Julien-zte> @[1]JonasB, the bonding interfaces is used in auto-deployment, and will perform yardstick, functest after that. It is not just depoyed and use it for development. In NFV, HA  or redundancy is very import feature.
15:07:02 <collabot`> Julien-zte: Error: "1" is not a valid command.
15:07:10 <mskalski> zhihui_wu: you point to the fix, which will be include in colorado, in case of bramaphutra you can just use newer version of the plugin
15:07:54 <[1]JonasB> Zhihi_wu: I think Bonding without ODL should follow the normal Fuel Yaml format, for ODL managed traffic interfaces it should be handled by the ODL plugin.
15:08:06 <[1]JonasB> mskalski: Do yo have another view?
15:08:28 <Julien-zte> @mskalski, I think it will be included in Colorado and if possible can be fixed in Brahmaputra
15:08:28 <collabot`> Julien-zte: Error: "mskalski," is not a valid command.
15:08:37 <greg__> got to run
15:08:52 <greg__> can somebody terminate the meeting once the discussion concludes
15:09:24 <z0d> #endmeeting
15:09:56 <mskalski> Julien-zte: there is no plan for another SR release of bramaputhra, but this fix is also backported to the plugin version which support Fuel 8.0 used in B release
15:10:55 <mskalski> Julien-zte: so you can build plugin based on 8.0 branch of odl plugin: https://github.com/openstack/fuel-plugin-opendaylight/tree/8.0
15:11:50 <Julien-zte> mskalski, do you mean that it  will be implemented using plugin not current method?
15:12:24 <Julien-zte> and it will be integrated in odl plugin of fuel?
15:14:00 <mskalski> but what will be implemented? bonding interfaces is built-in functionality of Fuel and it works, in case of ODL plugin where custom network transformation is done there was a bug regarding which is now fixed, but not included on the version which you find on ISO
15:14:55 <mskalski> but you can build plugin by self
15:15:05 <Julien-zte> understood
15:15:25 <Julien-zte> you mean that we can build odl plugin and used it for deployment
15:15:36 <Julien-zte> and the issue will be resolved
15:16:17 <Julien-zte> hi, mskalski, 3.0 including this fix or not?
15:17:22 <mskalski> yes, zhihui_wu confirmed that this commit fixes issue with bonds https://github.com/openstack/fuel-plugin-opendaylight/commit/d6966850f119e072b31d8dca1e0fb4c5f8fd0e21
15:18:52 <greg__> #endmeeting