16:01:47 <s3wong> #startmeeting tacker
16:01:48 <openstack> Meeting started Thu Jun  4 16:01:47 2015 UTC and is due to finish in 60 minutes.  The chair is s3wong. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:52 <openstack> The meeting name has been set to 'tacker'
16:02:16 <s3wong> Here is the agenda for today:
16:02:16 <s3wong> #link https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_June_4.2C_2015
16:02:31 <s3wong> #topic announcements
16:02:58 <s3wong> first, the "major" announcement is our new meeting time and channel
16:03:26 <s3wong> given that you guys are here, that means you already know about them; but for the record, I will info it
16:03:53 <s3wong> #info Tacker weekly meeting time and channel: Thursday @1600 UTC on #openstack-meeting
16:04:12 <gpaz> Hi everyone, Guy from Alcatel-Lucent (Cloudband)
16:04:21 <s3wong> gpaz: hello
16:04:30 <sridhar_ram> gpaz: hi
16:04:46 <s3wong> Several times this week, there has been inquiry on setting up Tacker demo
16:05:03 <s3wong> so I will also "announce" the detail as info
16:05:11 <ljlamers> #info Larry Lamers
16:05:27 <s3wong> ljlamers: hello
16:05:37 <sridhar_ram> s3wong: there were asks for a short installation doc as well
16:05:52 <sridhar_ram> folks are trying to stand up tacker service
16:06:13 <s3wong> #info the folder where we store most of our demo related things is here:
16:06:24 <s3wong> #link https://drive.google.com/folderview?id=0B4LNMvjOzyDufnhtanB2STZuUnlWVGpGcnRrMkxRdGE3TDZfblFqZjhjcnAzc3BsSEFCc3c&usp=sharing
16:06:58 <bobh> We were able to reproduce the demo except for the Horizon integration.  There seems to be a bug in the tacker Horizon repo that prevents Horizon from starting
16:07:05 <s3wong> #info devstack (in case you want a reference to local.conf) is in:
16:07:17 <s3wong> #link https://github.com/yamahata/devstack/tree/tacker-devstack
16:07:27 <s3wong> #info and Horizon repo is in:
16:07:36 <sridhar_ram> bobh: I can help
16:07:44 <s3wong> #link https://github.com/srics/horizon/tree/tacker
16:08:07 <s3wong> bobh: yeah, I feel much more confident after you were able to reproduce the demo setup (sans Horizon)
16:08:18 <s3wong> sridhar_ram: thanks!
16:08:29 <s3wong> any other announcements?
16:09:06 <sridhar_ram> ljlamers: is hosting a TOSCA meetup this monday
16:09:45 <s3wong> sridhar_ram, ljlamers: Monday the 15th, right?
16:09:53 <ljlamers> #info - Larry Lamers is not hosting a TOSCA meeting
16:10:28 <s3wong> ljlamers: not?
16:10:32 <ljlamers> #info Larry Lamers has invited several experts to a meet up including folks from OpenStack world
16:10:37 <sridhar_ram> ljlamers: can u clarify ?
16:10:49 <sridhar_ram> ljlamers: got it :)
16:11:08 <s3wong> OK, moving on :-)
16:11:16 <ljlamers> It is an informal meeting of experts - under no organization auspices
16:11:32 <sridhar_ram> ljlamers: sounds good
16:11:40 <s3wong> ljlamers: good
16:12:02 <s3wong> #topic Liberty cycle priorities
16:12:31 <s3wong> I tentatively put in a list of tasks on the agenda wiki
16:12:51 <sridhar_ram> s3wong: we also have an etherpad now to capture liberty tacker activities .. including the priority
16:12:55 <sridhar_ram> #link https://etherpad.openstack.org/p/liberty-tacker
16:13:13 <s3wong> the list, of course, should be finalized by community consensus
16:13:23 <s3wong> sridhar_ram: thanks
16:13:52 <s3wong> but just to get discussion going, let's go through these
16:14:04 <dgollub> what do you think about fixing up the run_tests.sh/testsuite and do "s/servicevm/vnf/" cleanups?
16:14:31 <s3wong> dgollub: that would also be important
16:14:46 <s3wong> dgollub: we will add that to the list
16:14:49 <dgollub> The original goal of tacker might confuse people if they look into the code right now - or do you think this is just nitpicking since it's just some naming thing ...
16:15:17 <sridhar_ram> dgollub: most of the APIs and CLIs has be changed over to "vnf" ..
16:15:32 <dgollub> oh, perfect. I haven't checked since the summit - just returned from PTO
16:15:42 <s3wong> dgollub: prior to the talk at the L-Summit, yamahata, sridhar_ram, and I rushed to do a name change
16:15:54 <dgollub> perfect
16:16:04 <s3wong> dgollub: but absolutely --- if we still have references to servicevm, we should fix them
16:16:16 <s3wong> dgollub: thanks for your input
16:16:40 <s3wong> So... item #1: monitoring driver
16:16:51 <bobh> would it make sense to work on the default tacker.conf file to make it easier to see what needs to be configured?
16:17:13 <s3wong> bobh: absolutely
16:17:18 <bobh> It was not obvious at first glance which sections are important and what the values should be
16:17:22 <sridhar_ram> bobh: agree, it is currently based on neutron.conf .. is it messy!
16:17:28 <s3wong> bobh: for the demo, we only have "default"
16:17:54 <sridhar_ram> bobh: we should clean that up
16:18:01 <s3wong> bobh: such as heat driver, or the ssh config driver :-)
16:18:15 <bobh> little things like that :-)
16:18:33 <s3wong> bobh: I agree that we should put together a tacker.conf
16:19:05 <s3wong> anyone wants to get started on this?
16:19:36 <sridhar_ram> s3wong: I can give it a shot
16:19:45 <s3wong> sridhar_ram: cool
16:20:17 <sripriya> sridhar_ram: i can help too if needed
16:20:39 <s3wong> #action sridhar_ram and sripriya will take the first crack on tacker.conf to clarify what components can be
16:20:40 <sridhar_ram> sripriya: sure, we can discuss this, thanks!
16:20:40 <bobh> sridhar_ram: me too
16:21:03 <s3wong> #action and bobh also (on tacker.conf)
16:21:10 <s3wong> very good, thanks guys!
16:21:24 <sridhar_ram> bobh: thanks, we can sync up over a patchset and colloborate
16:21:35 <bobh> sridhar_ram: Sounds good
16:22:16 <s3wong> Item #2: Monitoring
16:23:11 <s3wong> (sorry, updating the etherpad as I go)
16:23:29 <s3wong> currently, there is NO driver/plugin framework for monitoring
16:23:52 <melisha> Did you already have some alternatives in mind?
16:24:07 <s3wong> in fact, all we did was integrating what prashant wrote (ping thread every 5 seconds) and do it as connectivity check
16:25:02 <s3wong> melisha: well, at the very least we need to make it a driver interface; but as we talked about during the summit, in addition to health, monitoring should also do performance monitoring
16:25:03 <melisha> OK. We are now in the process of evaluating a monitoring service.
16:25:18 <melisha> We want something to be good for both HW and SW
16:25:39 <s3wong> melisha: and for that, for sure, this should be VNF specific as well as some common things
16:25:55 <dgollub> melisha: do you already have a certain interface in mind? (don't know what ETSI NFV is refering to here .. I'm new to the monitoring aspect)
16:26:07 <melisha> s3wong: so we are now talking only on the driver?
16:26:11 <sridhar_ram> melisha: s3wong: we need some default VNF / VIM level monitoring that is not VNF specific
16:26:20 <bobh> Maybe start with something simple like remote port monitoring
16:26:37 <s3wong> melisha: so in essence, we need to be able to plug in multiple drivers a la ML2 in Neutron
16:26:49 <bobh> may need to monitor a VM or also monitor via a proxy like an EMS
16:27:22 <sridhar_ram> how about  we write a blueprint in the tacker-specs repo for Tacker Health Monitoring
16:27:28 <s3wong> bobh: we need both the framework to allow vendor/VNF plugins, and reference implementation
16:27:37 <s3wong> sridhar_ram: I agree
16:27:47 <melisha> sridhar_ram: I agree
16:27:49 <sridhar_ram> we can discuss all these options in gerritt and pick the best approach
16:27:55 <s3wong> I think since this is a redesign, we should treat it as a new feature
16:28:07 <sridhar_ram> s3wong: agree
16:28:08 <bobh> s3wong: I agree.  Need to be able to have multiple different monitors in the same VNF
16:28:14 <s3wong> so we should go through the normal OpenStack process for bp and spec
16:28:31 <dgollub> I hope ETSI NFV has a answer to monitoring .. like netconf/yang for config stuff.
16:28:58 <dgollub> And in the end we have one set of well established driver for monitoring and config which work for several vendor VNFs
16:29:16 <s3wong> dgollub: while it is great to have --- but different VNF has very different monitoring parameters, not sure if ETSI can standardize that easily
16:29:19 <dgollub> so if there are others vendors out there interested not spinning their own vendor-specific thing ... let me know
16:30:00 <dgollub> what ETSI NFV seems to do is they just mention some random interface/protocols in the appendinx .. and the industry takes that as granted. Like netconf/yang and tosca and Heat and such things
16:30:29 <sridhar_ram> IMO ETSI NFV is an architectural framework and it is not as prescriptive in these areas
16:30:32 <dgollub> Ideally we just lead the industry with a good multi-vendor driver implementaiton -as referene
16:30:34 <bobh> some standard EMS interfaces may be useful - SNMP, JMS, etc for monitoring alarms and performance metrics
16:31:28 <s3wong> dgollub: +1 --- I think in Tacker we will start with some vendor agnostic things
16:32:21 <s3wong> bobh: agreed, narrow down to a set of common denominators, and start from there
16:33:04 <sridhar_ram> s3wong: yeah, some default monitoring + config methids (like config driver) which can be augmented by VNF specific .. will be good approach for Tacker
16:33:04 <s3wong> So... anyone interested in taking the first crack at monitoring framework?
16:33:44 <prashant> s3wong : I can get started on it
16:33:46 <s3wong> sridhar_ram: certainly. we definitely need to enhance what we have now
16:33:51 <bobh> I'm willing to help
16:33:52 <s3wong> prashant: nice
16:33:56 <s3wong> bobh: great
16:34:34 <s3wong> bobh, prashant: so as we talked about before, this is a new feature, so we need a bp and a spec for discussion. Let's start with that
16:35:01 <s3wong> #action bobh and prashant will start to look at the monitoring framework for Tacker
16:35:12 <s3wong> bobh, prashant: thanks, guys!
16:35:46 <s3wong> Next item (#3): config driver refactoring
16:36:28 <s3wong> config driver is actually a driver interface now, but there are certain things that need enhancement
16:37:03 <sridhar_ram> s3wong: i think basic thing we need to facilitate here is config-drive support
16:37:32 <s3wong> a.) while undoubtedly you guys were impressed with our ability to recover the config upon reboot; that config in txt format was store as a string in DB
16:37:34 <sridhar_ram> currently we have a openwrt / ssh based config support
16:37:49 <s3wong> 256 characters, I believe :-)
16:38:23 <s3wong> sridhar_ram: agreed, a bit of a hack to get things going
16:38:44 <sridhar_ram> config-drive support is lowest common denomintor, IMO
16:38:51 <dgollub> #info dgollub works on a usecase document for the OpenStack TelcoWorking group for VNF bring-up /instantiation - so the VNF vendor get some OpenStack VNF reference to agree on
16:39:21 <s3wong> dgollub: thanks
16:39:49 <sridhar_ram> dgollub: cool, i briefly talked Steve Gordan and he suggest to that do. Thanks!
16:40:20 <dgollub> I would be interested in some mix of config-drive for the initial bring up .. and later (optionally) more detailed managed via netconf/yang in case someone wants to run those VNFs without SDN controller or so
16:41:00 <sridhar_ram> dgollub: agree, we shd start with a simpler config-drive for the initial iteration..
16:41:17 <s3wong> sridhar_ram, dgollub: are you guys signing up for the task?
16:41:23 <dgollub> yep
16:41:44 <sridhar_ram> interaction with EMS and other southbounds like netconf/yang or SNMP needs further discussion
16:41:51 <s3wong> sridhar_ram: you too?
16:42:15 <sridhar_ram> sripriya: are you interested to pitch in here ?
16:42:20 <s3wong> sridhar_ram: yes, we can iterate and enhance as we go
16:42:24 <sripriya> s3wong: i can help backed by sridhar_ram
16:42:37 <s3wong> sripriya: cool, thanks
16:43:26 <s3wong> #action dgollub, sripriya with sridhar_ram's help to start looking at config driver and using config-drive as reference
16:44:07 <s3wong> Next item: TOSCA integration with Heat-Translator
16:44:40 <s3wong> currently Tacker has a built-in interpreter of TOSCA
16:44:40 <sridhar_ram> s3wong: this is critical and very important for Tacker!
16:45:04 <s3wong> after we wrote it, we found that (during the summit) Heat already has a functional TOSCA to Heat translator
16:45:28 <s3wong> and apparently, via the ML, Murano will have an interpreter as well
16:46:02 <dgollub> we should drive some effort that we all maintain only one interpreter/translator
16:46:28 <s3wong> so, for the demo, we took the liberty and added some private tags (like service_type) in our TOSCA files
16:46:39 <sridhar_ram> s3wong:  heat-translator used to be stackforge project and it got accepted into python-healtclient
16:46:55 <s3wong> sridhar_ram: OK
16:47:18 <s3wong> dgollub: +1 --- one of our main objective in Tacker is to NOT reinvent the wheel
16:47:30 <bobh> sridhar_ram: so it should be easy to incorporate via references to heat client?
16:47:31 <sridhar_ram> transition to heat-translator is little easier to chew for the initial iteration
16:48:02 <sridhar_ram> there are heat-translator APIs the tacker can invoke to feed the TOSCA and get a HOT template
16:48:46 <dgollub> anyone knows if there already exists TOSCA code in Murano? If there isn't any woring code yet, we might should just ignore it?
16:49:26 <s3wong> sridhar_ram: I haven't look at the heat-translator. But we do want existing functions to remain working once we move there. Can it do everything we need?
16:49:29 <melisha> sridhar_ram: heat-translator is not just a client thing? It exposes APIs?
16:50:08 <sridhar_ram> dgollub: we should plan to discuss Murano integration with some decent time to discuss. Shall we take that up for next week's IRC meeting Agenda?
16:50:25 <s3wong> dgollub: doesn't sound like it. Vahid from IBM volunteered to do it, so it seems to me they don't have anything yet
16:50:49 <s3wong> sridhar_ram: yes :-) I think we have enough tasks as is :-)
16:50:59 <sridhar_ram> #link https://github.com/openstack/heat-translator
16:51:21 <sridhar_ram> melisha: it offers APIs as well
16:51:23 <dgollub> let's discuss it next week - I met the PLT at the summit and told them about tacker. I'm going to invite him for the next IRC meeting if you like
16:51:31 <s3wong> sridhar_ram: though if you remember, the AT&T folks expressed interest on helping us with Murano integration
16:51:32 <dgollub> Murano PLT ...
16:51:50 <s3wong> sridhar_ram: don't think they are here...
16:52:05 <s3wong> dgollub: that would be great. Please do
16:52:07 <sridhar_ram> s3wong: dgollub: Absolutely, Murano is very important for us
16:52:37 <dgollub> So lets have a Murnano agenda thing for next weeks meeting
16:52:41 <sridhar_ram> but we need to put some thought and discuss that option..
16:52:52 <s3wong> sridhar_ram: so, are you going to look into heat-translator?
16:53:08 <s3wong> dgollub: sure, will add that for next week's agenda
16:53:14 <sridhar_ram> however .. transition from in-built translation to heat-translator is a smaller task
16:53:29 <sridhar_ram> s3wong: yes, i'm interested in heat-translator integration
16:53:34 <dgollub> I have concerns that Murano gets to big ... if they do TOSCA, orchestration, .... it becomes more and more HEAT + catalogue
16:54:04 <s3wong> dgollub: yeah, Murano then becomes OpenStack MANO :-)
16:54:13 <sridhar_ram> dgollub: that is my concern as well.. we depending too much on the *big* Murano.. it should be one of the options :)
16:54:47 <s3wong> #action sridhar_ram to look into heat-translator migration in Tacker
16:54:48 <sridhar_ram> time check .. we have just 5 more mins on the clocks
16:55:08 <s3wong> alright, we will also move HA discussion to next week
16:55:18 <s3wong> #topic Open Discussion
16:55:27 <s3wong> anything else to discuss?
16:55:42 <sridhar_ram> quick update on tacker-horizon repo
16:56:08 <sridhar_ram> the stackforge creation request is still pending on the openstack-infra team
16:56:22 <dgollub> https://github.com/stackforge/tacker - http://git.openstack.org/cgit/stackforge/tacker/ - are those the repos with the latest code? (At least the repo description still holds service-vm traces)
16:56:40 <s3wong> dgollub: yes
16:57:01 <sridhar_ram> dgollub: there is also https://github.com/stackforge/tacker-specs for blueprints
16:57:06 <s3wong> dgollub: will need to sweep through the servicevm references and change them
16:57:07 <dgollub> Are those also the repos where you did the mass-renaming already? There is only one change since the summit
16:57:27 <s3wong> dgollub: we did the name change before the summit
16:57:33 <dgollub> s3wong: ok cool - especially the repo description - this is something I can't change with a gerrit request I guess
16:57:33 <sridhar_ram> dgollub: we are changing the servicevm --> vnf nomenclature as we go.. will keep doing it :)
16:57:37 <s3wong> dgollub: but obviously not all references :-)
16:57:54 <s3wong> I think we should look into unit test. All these time we were cranking out functions, and did all testing on devstack.
16:58:22 <s3wong> but Tacker by nature is a bit difficult to have "unit test", well --- at least the API and DB should have them
16:58:39 <dgollub> +1 ... when I want to start hacking on a project the first thing I try is if the unit tests all pass ... if not -> bad first impression
16:58:55 <s3wong> I will take a look at that (as it is just grunt work, so I don't want to subject new contributors to those) :-)
16:59:12 <dgollub> I can help with that
16:59:21 <s3wong> dgollub: wow, cool. Thanks!
16:59:36 <s3wong> OK, time is almost up, anything else?
17:00:13 <s3wong> Thanks, everyone. Especially thanks for all those who agreed to do work. Talk to you guys next week
17:00:15 <sridhar_ram> i think we are good!
17:00:24 <s3wong> #endmeeting