16:00:17 <trevor_intel> #startmeeting OPNFV Pharos
16:00:17 <collabot> Meeting started Wed Dec  9 16:00:17 2015 UTC.  The chair is trevor_intel. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:17 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:17 <collabot> The meeting name has been set to 'opnfv_pharos'
16:00:25 <mbeierl> I just wrapped up the StorPerf meeting in GTM, so yes, it's free
16:00:31 <mbeierl> Is there a GTM link?
16:00:34 <frankbrockners> Hi folks we also have an audio meeting active: https://global.gotomeeting.com/join/605217581
16:02:17 <ljlamers__> #info Larry Lamers
16:02:25 <timirnich> #info Tim Irnich
16:02:28 <frankbrockners> #info Frank Brockners
16:02:34 <zhipeng> #info howard huang
16:02:39 <[1]JonasB> #infoJonassss Bjurel
16:02:41 <trevor_intel> #info trevor_intel
16:02:42 <mbeierl> #info Mark Beierl (StorPerf)
16:02:47 <[1]JonasB> #info Jonas Bjurel
16:02:55 <debrascott> #link https://global.gotomeeting.com/join/918206221
16:02:56 <frankbrockners> Tim, Larry - we also have an audio bridge: https://global.gotomeeting.com/join/605217581
16:02:57 <n0ano> #info Don Dugger (KVM)
16:02:58 <bin_> #info Bin Hu (IPv6)
16:03:24 <s_berg> #info Stefan Berg
16:03:36 <iMSWynne> #info Michael Wynne
16:03:52 <debrascott> oops, sorry don’t want to confuse. Let’s use the audio that frankbrokners posted
16:04:09 <trevor_intel> frankbrockners: please can you chair the meeting ... I need to drop off in 15 min
16:05:34 <dandruta> #info Dan Druta
16:06:21 <trevor_intel> #chair frankbrockners
16:06:21 <collabot> Current chairs: frankbrockners trevor_intel
16:06:27 <iben> #info Iben Rodriguez
16:06:54 <trevor_intel> We need somebody to take notes
16:07:05 <mbeierl> That's me
16:07:10 <frankbrockners> #chair mbeierl
16:07:10 <collabot> Current chairs: frankbrockners mbeierl trevor_intel
16:08:19 <billyoma> #info Billy O'Mahony (OVSNFV & VSPERF)
16:08:24 <mbeierl> #info Continue discussion on common installer files and configuration - but are missing some key installer folks
16:08:46 <mbeierl> #Topic How to build a plugin
16:08:53 <mdgray> #info Mark Gray
16:08:57 <[1]JonasB> #link https://wiki.opnfv.org/fuel_opnfv_integrated-project-guidelines
16:09:59 <mbeierl> #info the desire is that each  project creates  their own installer plugin with help from the installer members
16:10:35 <mbeierl> #info if a project needs something installed, the project needs to drive that
16:11:04 <mbeierl> #action Each project identifies what they need and create JIRA tickets for each installer
16:11:45 <mbeierl> #info and make sure the project assigns the JIRA ticket to someone
16:11:56 <iben> thanks mbeierl
16:13:25 <mbeierl> #info Bryan wants to set expectation that the project creates one standard way of driving their installation requirement, and then the installer plugins are a thin wrapper to the project
16:15:07 <mbeierl> #info Michael echos that all four installers is too large of a goal for Brahmaputra.  Same comment from Tim
16:16:11 <mbeierl> #info Jonas states that it should not be the case, that for example, puppet or ansible should be easier to integrate
16:16:48 <mbeierl> #info Common use of ansible or puppet with a shim layer should be doable
16:17:03 <mbeierl> #info How does each project know what is the right thing to do?
16:17:54 <mbeierl> #info High level requirements for install process: say, provide puppet or ansible, and then talk to installer team to integrate it
16:18:02 <[1]JonasB> #link https://wiki.opnfv.org/fuel_opnfv_integrated-project-guidelines
16:18:40 <mbeierl> #info: Suggestion - use either of the two, and then each installer can provide simple wiki overview
16:18:47 <mbeierl> #info See link above for example
16:19:06 <mbeierl> #info Compass will update overview and send to mailing list
16:19:22 <mbeierl> #info Apex will create and send out (Tim)
16:19:30 <iben> can I post?  I’m not a chair
16:19:39 <mbeierl> anyone can #info
16:19:45 <frankbrockners> #chair iben
16:19:45 <collabot> Current chairs: frankbrockners iben mbeierl trevor_intel
16:19:48 <iben> #info #link JOID charm (plugin) more info : https://wiki.opnfv.org/joid?&#juju_and_maas_training_materials
16:20:11 <iben> thx frankbrockners
16:21:22 <mbeierl> #info: Bryan proposes instead of putting onus on installer projects to make it happen - that the individual teams also share info and root that in a central wiki.  Here is who is working and here is the icr channel
16:21:43 <mbeierl> #info Create an end use wiki approach
16:22:19 <mbeierl> #info Mark Gray - agrees wiki is good, but when things go wrong, we don't have the expertise
16:22:40 <mbeierl> #info this might slow things down for the core of what the project actually wants to do
16:22:58 <mbeierl> #info puts a lot of burden on the project
16:23:27 <frankbrockners> #link https://wiki.opnfv.org/genesis - now includes to above links to "HOWTO integrate with an installer"
16:23:57 <mbeierl> #info Billy: agrees wiki is nice, but would like to see an example ... and then audio was lost :(
16:24:48 <mbeierl> #info Mark G: is there a strong requirement to support all installers?
16:25:15 <[1]JonasB> info: Example of Fuel plugin for ovs-nsh-dpdk      https://review.openstack.org/#/c/222066/1
16:25:23 <mbeierl> #info: encouraged but not required.  Iben: example is (perhaps) KVM which is only Ubuntu, therefore not all installers would be valid
16:25:52 <mbeierl> #info: Bryan - can we have a description of the end state of system after the installation is complete
16:26:21 <mbeierl> #info Are all OpenStack services installed on the bare metal host, or are they in containers, and does this change the plugin approach?
16:26:42 <mbeierl> #info Not everyone was aware that there is that type of variance
16:27:05 <mbeierl> #info That is part of what Genesis tries to define? - Frank
16:27:31 <[1]JonasB> billy: did you see the OVS example above?
16:27:39 <mbeierl> #info based on the distro that is being installed, certain features are available
16:28:04 <mbeierl> #link  https://review.openstack.org/#/c/222066/1
16:28:24 <mbeierl> #info: Example of Fuel plugin for ovs-nsh-dpdk https://review.openstack.org/#/c/222066/1 (from JonasB)
16:28:59 <mbeierl> #info Bryan asks why installers choose different (container vs bare metal) approaches
16:29:14 <mbeierl> #info Would be good to have that as part of the overview of the installer project itself
16:29:48 <mbeierl> #info  Who would  be qualified to answer that?  Yardstick or other project that has done all 4?
16:30:09 <mbeierl> #info Yardstick does not do plugin, they use OpenStack APIs
16:30:40 <mbeierl> #info Is there an example available that other projects could study and learn?
16:31:00 <mbeierl> #action Put that out as a question to the list
16:31:15 <mbeierl> #info Not sure if there is one example that does work against all the installers
16:31:43 <mbeierl> #info Frank reminds that installers themselves are also  moving targets, so they are not complete either
16:32:04 <mbeierl> #info Best thing is to gather information, write up guides and share
16:32:42 <mbeierl> #info Frank has updated Genesis as per link above
16:33:51 <mbeierl> #info Reminder to please engage on IRC channels for installer teams
16:35:20 <mbeierl> #info installers install the platform - network controller, storage, etc.  Then test project comes in and runs tests
16:35:25 <billyoma> Hi All - as my audio is gone...
16:35:25 <billyoma> What I would like to see installer projects providing is not just a wiki but a working example.
16:35:25 <billyoma> An end-to-end 'hello-world' plugin/charm/etc. This example plugin would have code for a plugin that  would install a) install a package (rpm/deb/etc) on some nodes and b) also run a puppet manifest and/or an ansible playbook (depending on what the installer supports) c) the example MUST support deployment on a single standard server (10-20 core/ 20-30 GB ram
16:35:26 <billyoma> / ~200GB disk).
16:35:26 <billyoma> Requiring several physical nodes (and attendant networking effort and expertise) to deploy  is a massive barrier.
16:35:26 <billyoma> Hopefully I would have something like this ready for fuel in the near future.
16:35:26 <billyoma> This is like operating system wars where the successful OSs are the ones that make it easiest (or at least most praticable) for developers to write programs.
16:36:22 <mbeierl> #info Test projects might install their own test VM - say a glance image - and then runs
16:36:33 <mbeierl> #info Or even a HOT or Jenkins jobs
16:38:14 <mbeierl> #info Example: Congress requires something extra installed in the OpenStack platform, therefore needs an integration point with the installer for that part
16:39:10 <mbeierl> #info Example: other projects might require specific distro and therefore would only use one installer
16:40:14 <mbeierl> #info Determine if you are just consuming the platform (eg: test platform) or if you are part of the platform
16:41:08 <mbeierl> #info If that is required for all four installers, it is appreciated that you help integrate in all
16:42:57 <trevor_intel> frankbrockners: at end of the meeting please try to agree some agenda topics for Thursday (since we agreed to use the Test meeting as one of the weekly meetings to continue the release discussions)
16:43:39 <frankbrockners> trevor_intel: thanks for the reminder - will do
16:43:50 <mbeierl> #info from Billy: An end-to-end 'hello-world' plugin/charm/etc. This example plugin would have code for a plugin that  would install a) install a package (rpm/deb/etc) on some nodes and b) also run a puppet manifest and/or an ansible playbook (depending on what the installer supports) c) the example MUST support deployment on a single standard server (10-20 core/ 20-30 GB ram / ~200GB disk).
16:44:28 <mbeierl> #info from Billy: Requiring several physical nodes (and attendant networking effort and expertise) to deploy  is a massive barrier. Hopefully I would have something like this ready for fuel in the near future.  This is like operating system wars where the successful OSs are the ones that make it easiest (or at least most praticable) for developers to write programs.
16:45:08 <mbeierl> #info Iben suggest we need to think of this as "get the feature installed in OpenStack" vs. "get it installed on Ubuntu"
16:45:51 <mbeierl> #info The question was - has anyone does this already?  Answer appears to be no, so Compass might actually be that example, so they will work towards documenting their experience
16:46:04 <iben> not compass
16:46:18 <iben> congress / copper
16:46:28 <iben> openstack congress = opnfv copper
16:46:34 <mbeierl> #undo
16:46:34 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2eff950>
16:46:44 <mbeierl> #info The question was - has anyone does this already?  Answer appears to be no, so Congress might actually be that example, so they will work towards documenting their experience
16:46:49 <mbeierl> thanks, iben
16:46:53 <iben> yup
16:47:00 <mbeierl> #topic Common inventory and common config
16:49:26 <frankbrockners> #link https://gerrit.opnfv.org/gerrit/#/c/4079/
16:49:34 <mbeierl> #info has everyone seen the link and had a chance too review and comment?
16:49:50 <mbeierl> #undo
16:49:50 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2e89650>
16:49:57 <mbeierl> #info has everyone seen the link and had a chance to review and comment?
16:50:35 <mbeierl> #info This is for an installer to use when installing in a new lab, not for projects
16:51:13 <mbeierl> #info For a CI perspective, this is how to make things simpler, so you don't have to deal with so many differences in installers
16:51:43 <mbeierl> #info This is meant to be an extensible framework for future configs
16:52:04 <mbeierl> #info Example: L3VPN needs certain ODL features in order to run
16:52:22 <mbeierl> #info As part of the configuration, these things need to be turned on/off
16:52:52 <mbeierl> #info Not targeting to make /everything/ configurable, but focus on OPNFV requirements instead of generic language
16:53:13 <mbeierl> #info Will it describe the Jump Host - the networks between it and the rest of the POD?
16:53:26 <mbeierl> #info VLANs, etc are different
16:53:44 <mbeierl> #info Yes, want to harmonize this
16:54:08 <frankbrockners> #link https://gerrit.opnfv.org/gerrit/#/c/4095/
16:54:35 <mbeierl> #info Is this retroactive?  When do we start using it?
16:54:53 <mbeierl> #info Frank - want to use it for Brahmaputra
16:55:27 <mbeierl> #info As soon as we are able to deploy, want to use the scripts be interpreted and have the installer create their own config from this meta config data
16:55:43 <mbeierl> #info Will there be a wiremap?
16:55:53 <mbeierl> #info That is the ambition/plan
16:56:56 <mbeierl> #info To review: how to describe? see 4095 for that as well
16:57:47 <mbeierl> #info Use YAML to describe this   - Tim to come up with a common description
16:58:07 <mbeierl> #info Tim R, not I.
16:58:51 <mbeierl> #action Everyone to review Jonas' proposal
16:59:22 <mbeierl> #info Plan to conclude this in tomorrow's testing call
17:00:06 <mbeierl> #action frankbrokners to send out email about tomorrow's call
17:00:50 <mbeierl> #info Email tags will be "as many as possible" testing, genesis, pharos
17:01:13 <mbeierl> #info Frank has put agenda items up
17:02:00 <mbeierl> Anyone have further #infos?
17:02:11 <mbeierl> #endmeeting