17:03:10 <yamahata> #startmeeting servicevm-device-manager
17:03:11 <openstack> Meeting started Wed Nov 26 17:03:10 2014 UTC and is due to finish in 60 minutes.  The chair is yamahata. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:03:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:03:15 <openstack> The meeting name has been set to 'servicevm_device_manager'
17:03:24 <yamahata> #chair s3wong bobmel
17:03:25 <openstack> Current chairs: bobmel s3wong yamahata
17:03:54 <yamahata> #link https://wiki.openstack.org/wiki/Meetings/ServiceVM agenda
17:04:07 <yamahata> #topic Announcement
17:04:36 <yamahata> #info neutron subteam charter page is created
17:04:40 <yamahata> #link https://wiki.openstack.org/wiki/NeutronSubteamCharters
17:05:25 <yamahata> Should we list our team there?
17:05:53 <s3wong> yamahata: are we Neutron subteam?
17:06:09 <SridharRamaswamy> yamahata: i was pondering the same!
17:06:17 <yamahata> s3wong: No officially, I think.
17:06:37 <yamahata> So I hesitate to do.
17:06:39 <s3wong> yamahata: we are a stackforge project, so technically not part of Neutron...
17:07:06 <bobmel> Maybe more important to be visible in adv.services
17:07:28 <bobmel> Like, ensure we report on progress, updates etc
17:07:35 <s3wong> (actually we aren't even a Neutron service plugin)
17:07:45 <yamahata> bobmel: makes sense.
17:08:02 <SridharRamaswamy> but it will be good to operate just like an official subteam ... with proper charter, deliverable for kil, exit criteria
17:08:20 <SridharRamaswamy> s/kil/kilo/
17:08:56 <s3wong> bobmel: speaking of that --- from mestery 's latest comment, he now suggests that there will be multiple repos for advanced services (basically one per service type)
17:09:12 <yamahata> SridharRamaswamy: So as sub-sub team of adv. service team?
17:09:35 <SridharRamaswamy> yamahata: perhaps yeah
17:09:53 <s3wong> yamahata: if advanced service becomes ONE team with one repo, I suppose tacker should eventually be part of this new advanced service project
17:09:53 <bobmel> s3wong: Yes I saw that.
17:10:21 <s3wong> yamahata: but the current thinking is that advanced services would be split into multiple repo
17:10:43 <hareeshp> wondering if repos for each service is a good idea
17:10:43 <SridarK> sorry just lurking - but at some point was it not said that service vm's could be of interest outside of neutron too ?
17:11:17 <s3wong> hareeshp: I don't think it is, honestly (certainly not for VPNaaS :-) )
17:12:03 <s3wong> SridarK: we can go either direction, I suppose. But given the background of the team members here, it may make sense to put initial focus on only network services
17:12:41 <s3wong> (but that is just my opinion, the team will decide in the long run :-)  )
17:12:58 <yamahata> By looking at the charter page, it tracks spec/patch reviews. So it would make sense to put our neutron spec/patches
17:13:04 <SridarK> s3wong: makes sense - and i also agree that most interest and need is on network services - just wanted throw that out there so there is no confusion later on
17:13:56 <SridharRamaswamy> SridarK: i though that was reason used to throw tacker out of neutron ;-)
17:14:17 <SridarK> SridharRamaswamy: yes that was the thought
17:14:40 <s3wong> SridharRamaswamy: certainly a reason from the PTL's POV, but how the project moves forward is up to the team
17:15:51 <SridharRamaswamy> on this subject .. does anyone know a non-networking, non-neutron use-case for tacker ?
17:16:26 <SridharRamaswamy> i keep hearing some hypothetical storage-service-vm..
17:16:36 <yamahata> I know none so far...
17:16:39 <s3wong> SridharRamaswamy: kind of difficult to think that far given that the network services related use cases for tacker hasn't been ironed out yet :-)
17:17:03 <SridharRamaswamy> if there is real need .. then we could include in the use-case
17:17:36 <SridharRamaswamy> s3wong: okay, i guess it make sense to "live" under adv.services umbrella for the initial few iterations...
17:17:55 <bobmel> SridharRamaswamy: +1
17:18:23 <SridarK> SridharRamaswamy: +1
17:18:36 <pgpuany> hi all Are we on workflow disucssions?
17:18:49 <s3wong> yamahata: yes, let's move on :-)
17:18:51 <bobmel> Do I dare raise the question about wsgi framework to use sometime during this irc?
17:19:00 <yamahata> #agreed tacker "live" under adv. service for a while
17:19:13 * hareeshp wondering what is upto :)
17:19:26 <yamahata> let's discuss it after action items
17:19:35 * hareeshp wondering what bobme is upto ;)
17:19:36 <yamahata> #topic Action Items from the last week
17:19:37 <pgpuany> ok
17:19:46 <bobmel> yamahata: yes.ok
17:20:20 <yamahata> The left action item is to determine webex meeting.
17:20:25 * s3wong would be interested to find out what bobmel has in store for wsgi framework discussion
17:20:40 <yamahata> The poll page is already created, so we can determine later.
17:20:51 <yamahata> anything else?
17:21:05 <yamahata> move on...
17:21:06 <yamahata> #topic spec/code review
17:21:20 <yamahata> bobmel: please go ahead
17:21:53 <bobmel> yamahata: you mean regarding wsgi to use?
17:21:59 <yamahata> bobmel: yes.
17:22:22 <yamahata> #link https://docs.google.com/document/d/1xs8TvEVMszzND5uoWTHtd1tJnu7105Ekgq9hxiyXABQ/edit?pli=1
17:22:30 <bobmel> Just a thought that came to me as in ways we're starting up tacker
17:22:30 <s3wong> yamahata: that doesn't match the topic? :-)
17:22:57 <yamahata> #undo
17:22:57 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x1e041d0>
17:23:02 <yamahata> #topic api/workflow review
17:23:09 <bobmel> and we started off from Neutron's code base (for natural reasons) but now Neutron is heading towards Pecan
17:23:19 <bobmel> and seemingly other OS services too
17:23:42 <bobmel> So, should we start with what we have?
17:24:03 <bobmel> And later evaluate to adopt something like Pecan?
17:24:33 <yamahata> bobmel: I agree we should decide the direction ASAP
17:25:07 <yamahata> because the early development stage is a good chance to change it.
17:25:32 <s3wong> bobmel: we have little to no dependency on any module, so it should be OK to switch from the get-go
17:25:34 <yamahata> changing it later would require big effort.
17:25:40 <bobmel> yamahata: That was my thinking too. If we are to change, then perhaps it is best to do it like now
17:26:05 <pgpuany> Good idea to switch to light weight web framework Pecan now at early stage
17:26:24 <SridharRamaswamy> bobmel: i wish api server infra goes to oslo so all the service can reuse it...
17:26:31 <pgpuany> k1 timeframe we can catchup using Pecan
17:27:06 <yamahata> What about other projects? nova?
17:27:23 <bobmel> Do we have people in this team who are up to speed on Pecan? I'm a novice myself.
17:28:00 <bobmel> yamahata: Ceilometer uses it
17:28:14 <pgpuany> may be we can start with base application tempalte
17:28:17 <pgpuany> https://pecan.readthedocs.org/en/latest/quick_start.html#base-application-template
17:28:27 <yamahata> bobmel: so pecan sounds promising.
17:29:45 <SridharRamaswamy> bobmel: just a thought.. can't we use adv.services or neutron endpoint for now for tacker
17:29:46 <yamahata> okay I'll check pecan.
17:30:15 <pgpuany> sure as dealing with less scss on hrizon /django can be avoided
17:30:18 <bobmel> SridharRamaswamy: Technically I think tacker could be another service plugin
17:30:34 <SridharRamaswamy> I'm worried we will be spinning pecan(!) in tacker before addressing actual use-cases tacker is going after
17:31:25 <SridharRamaswamy> can't we let adv.services / neutron solve the switch over to pecan.. we can just leverage (copy!) the work
17:31:29 <bobmel> SridharRamaswamy: That is a valid point
17:31:57 <pgpuany> Afterall its just API & JSON rest is still retained even if we use Pecan
17:31:59 <yamahata> Sure that's option.
17:32:54 <bobmel> pgpuany: So you're saying the we can propbably reuse much of what is in Tacker repo?
17:33:04 <pgpuany> I think chekout Pecan one of of them and rest continue on tracker
17:33:09 <bobmel> pgpuany: I mean for DB stuff etc
17:33:20 <pgpuany> yes looks like that to me
17:33:28 <pgpuany> yes
17:34:21 <SridharRamaswamy> i would suggest we wait for out mothership to do the switch over and then we follow .. deliberately delay to leverage..
17:34:24 <pgpuany> Although it is lightweight, Pecan does offer an extensive feature set for building HTTP-based applications, including:
17:34:24 <pgpuany> Object-dispatch for easy routing
17:34:24 <pgpuany> Full support for REST-style controllers
17:34:24 <pgpuany> Extensible security framework
17:34:24 <pgpuany> Extensible template language support
17:34:24 <pgpuany> Extensible JSON support
17:34:24 <pgpuany> Easy Python-based configuration
17:35:17 <pgpuany> OK lets get one to play and report next week before taking decision
17:35:35 <yamahata> pgpuany: volunteer?
17:36:10 <pgpuany> OK I will review pecan and report back (I am pgpus) and pramchan@yahoo.com , will report next week on pecan
17:36:21 <yamahata> pgpuany: cool
17:36:36 <yamahata> #action pgpuany review pecan and report back
17:36:37 <pgpuany> nop
17:36:57 <bobmel> pgpuany: I think key is to figure out how much of existing code can be reused
17:37:25 <pgpuany> OK I am new where is the ServiceVM code to review
17:37:30 <bobmel> pgpuany: so adoption of pecan won't delay things too much
17:38:02 <yamahata> pgpuany: the code is just strip down version of neutron.
17:38:03 <pgpuany> after gerrit review of Service VM code and pecna will come with suggessions next wek
17:38:59 <yamahata> okay seems settled down.
17:39:06 <pgpuany> OK that's cool I have reviewed newutron plugin so when did we start Juno or havana?
17:39:14 <pgpuany> 2014.1 or 2014.2
17:40:11 <yamahata> juno
17:40:53 <yamahata> the fork point is not clean.
17:41:06 <yamahata> I used the HEAD at the point.
17:41:36 <pgpuany> OK so its in opesntack Juno main and not stackforge
17:42:06 <pgpuany> Thats fine all we need is to see code to see if Pecan has a plavce for us to use
17:42:37 <pgpuany> done - will reort next week, please proceeed with other items
17:42:56 <yamahata> bobmel: I think you have other dicussion points according to google-doc.
17:43:58 <bobmel> I need to open the doc...
17:44:28 <pgpuany> Anyway this needs code rveiew so will help  https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms
17:44:40 <yamahata> physical topology and agent notification
17:45:33 <pgpuany> Physical topology you mean like mininet node mode?
17:45:41 <pgpuany> model
17:45:55 <SridharRamaswamy> bobmel: those were good discussion points on physical topology.. are more things written somewhere on this topic ..
17:46:10 <bobmel> SridharRamaswamy: No not really.
17:46:11 <SridharRamaswamy> bobmel: they go into the realm of scheduling..
17:46:53 <yamahata> pgpuany: something like that.
17:46:54 <bobmel> Do you folks think it belongs in Tacker?
17:47:24 <yamahata> I think tacker is consumer of the info.
17:48:01 <yamahata> I don't expect physical topology will be available in near term in any form
17:48:03 <bobmel> yamahata: and to follow on that, it should then be like in Neutorn?
17:48:09 <yamahata> So we can safely defer it.
17:48:17 <SridharRamaswamy> yamahata: yes, lets differ it
17:48:38 <pgpuany> Thats like snapshot as I see
17:49:01 <bobmel> So we can place it last in the item list if we keep it.
17:49:10 <pgpuany> ok
17:49:12 <yamahata> bobmel: +1
17:50:27 <yamahata> #agreed defer physical topology and place it last in the item list if we keep it
17:50:42 <bobmel> Have everybody gone thorugh the spec doc?
17:50:49 <pgpuany> As long as a service is single node the physical topolgy attribs are limited but once multinode crreps in the snapshop will be complicated and agreed avoid in 1st cut
17:51:15 <SridharRamaswamy> bobmel: i went thru' once !
17:51:52 <hareeshp> need to do it
17:52:07 <SridharRamaswamy> it needs some "restructuring" IMO .. particularly the NFV / VNF texts
17:52:30 <yamahata> sure I did :-). I'm biased, so it would be desirable for someone else to revise/re-edit it...
17:52:58 <SridharRamaswamy> i can give it shot
17:53:07 <pgpuany> I have just reviewed and would like to add comments for detailing APIs and VNFM lifecyle management or atleast review in next 2-3 days
17:53:08 <s3wong> bobmel, yamahata: we would like to have more comments on the doc before having the webex session
17:53:30 <pgpuany> sure sounds good
17:53:42 <yamahata> s3wong: +1 for more comments/discussion before webex session
17:53:44 <SridharRamaswamy> yamahata: i think VNF / NFV relations are quite relevant..
17:54:07 <SridharRamaswamy> yamahata: just suggesting to re-organize for clarity
17:54:44 <yamahata> 5 min left.
17:54:51 <pgpuany> VNFs have more than CRUD APIs as they deal with topology placnment etc.
17:55:12 <pgpuany> Add review comments thic week +1
17:55:30 <yamahata> #action everyone review google-doc
17:55:52 <pgpuany> you mean https://docs.google.com/document/d/1xs8TvEVMszzND5uoWTHtd1tJnu7105Ekgq9hxiyXABQ/edit?pli=1#
17:55:57 <yamahata> pgpuany: yes
17:56:11 <s3wong> Yes --- all these suggestions/discussions should be brought over to the Google doc
17:56:16 <pgpuany> ok done we have long week end here to address this safely
17:56:50 <yamahata> Let's open discussion before closing...
17:56:51 <s3wong> I do expect a lot of comments (or additional suggestions inside the spec for those who can edit) over the next week or so (hopefully)
17:56:59 <yamahata> #topic Open Discussion
17:57:07 <pgpuany> Hope all you will Pardon the Turkey!!! not sure if this happens all over ... enjoy
17:57:09 <bobmel> yamahata: timeline
17:57:13 <bobmel> for Kilo
17:57:20 <bobmel> for Tacker
17:57:22 <yamahata> sorry for interrupting
17:57:24 <pgpuany> spell ou
17:57:31 <pgpuany> k1, k2?
17:57:53 <pgpuany> k1=dec 18
17:58:00 <SridharRamaswamy> doodle for the timeslot for the webex shows early next week..
17:58:16 <pgpuany> ok
17:58:16 <SridharRamaswamy> would we be ready early next week for the webex call ?
17:58:20 <bobmel> Can we outline one on the tacker wiki, what we should aim for in terms of deliverables
17:58:24 <yamahata> bobmel: What do you mean? do we want to set mile stone?
17:58:29 <s3wong> SridharRamaswamy: then I suppose we should have our comments on the doc by early next week :-)
17:58:53 <SridharRamaswamy> s3wong: yeah, then push webex to the week after ?
17:59:14 <SridharRamaswamy> s3wong: alteast later in the week
17:59:17 <yamahata> SridharRamaswamy: okay I will expand the range of doodle poll .
17:59:32 <s3wong> SridharRamaswamy: probably make sense for the team to read the comments/additions before having a webex
17:59:49 <yamahata> #action yamahata expand range of poll
17:59:58 <pgpuany> OK do I have permission to update googledoc, or I need to be permitted by some one from your side?
18:00:23 <s3wong> pgpuany: anyone can comment
18:00:30 <pgpuany> thanks
18:00:32 <yamahata> Time is coming.
18:00:47 <s3wong> pgpuany: but if you feel you want to add content in there, you can ping yamahata to add you as an editor
18:01:07 <yamahata> Given the recent meeting time, it will make sense to have 1hour slot instead of 30min.
18:01:14 <s3wong> and for those that can edit, please put your IRC handle (for example [s3wong]:) on pieces that you edit
18:01:16 <pgpuany> Is Service VM = Appliance?
18:01:27 <s3wong> yamahata: +1
18:01:32 <bobmel> yamahata: +1
18:01:39 <SridharRamaswamy> yamahata: +1
18:01:48 <yamahata> #action yamahata increase timeslot from 30min to 1hour
18:01:50 <s3wong> pgpuany: service "container", can be VM, software containers, or appliances
18:02:18 <pgpuany> you mean incuding Docker
18:02:27 <bobmel> yamahata: At some point not to distant future we probablyu need to have a reasonable idea what to aim for K1, k2 and k3
18:02:31 <s3wong> pgpuany: exactly
18:02:44 <pgpuany> I see so any container, does API address that with container type or soemthing?
18:02:49 <yamahata> bobmel: +1
18:02:59 <SridharRamaswamy> bobmel: +1, hopefully in line with what we agreed in the summit
18:03:07 <bobmel> yamahata: We can revisit that question next time.
18:03:14 <pgpuany> Container Type=VM, Docker,...
18:03:22 <pgpuany> OK we will thanks
18:03:28 <bobmel> SridharRamaswamy: Yes. Did we put that somewhere on the wiki?
18:03:46 <SridharRamaswamy> bobmel: yep, use-case table has specific release target
18:03:47 <s3wong> bobmel: didn't some of us take pictures of the whiteboard? :-)
18:04:13 <SridharRamaswamy> s3wong: all that info is captured in the use-case table..
18:04:14 <yamahata> The items are all in etherpad.
18:04:34 <s3wong> cool
18:04:35 <pgpuany> link to etherpad?
18:04:52 <bobmel> SridharRamaswamy: Oh yes, how could I miss that... :-)
18:04:56 <SridharRamaswamy> etherpad correct.... it is distilled into the use-case release target
18:05:05 <SridharRamaswamy> :)
18:05:19 <SridharRamaswamy> perhaps that picture is worth preserving ;-)
18:05:56 <SridharRamaswamy> pgpuany: #link https://etherpad.openstack.org/p/servicevm
18:06:01 <pgpuany> thanks
18:06:57 <yamahata> #endmeeting