13:05:30 <zhipeng> #startmeeting Tricircle
13:05:31 <openstack> Meeting started Wed Jul  8 13:05:30 2015 UTC and is due to finish in 60 minutes.  The chair is zhipeng. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:05:34 <openstack> The meeting name has been set to 'tricircle'
13:05:44 <zhipeng> #topic Roll Call
13:05:48 <zhipeng> #info zhipeng
13:05:53 <saggi> #info saggi
13:05:59 <zhiyuan> #info zhiyuan
13:06:01 <joehuang> #info joehuang
13:06:02 <gampel> #info gampel
13:06:32 <zhipeng> #info irenab
13:06:36 <zhipeng> anybody else ?
13:06:46 <joehuang> #link https://docs.google.com/document/d/19BXf0RhkH8wEEymE2eHHqoDZ67gnzgvpr3atk4qwdGs/edit#
13:07:00 <zhipeng> #topic design doc discussion
13:07:19 <zhipeng> #link https://docs.google.com/document/d/19BXf0RhkH8wEEymE2eHHqoDZ67gnzgvpr3atk4qwdGs/edit#heading=h.5r6zgqbiehsh
13:08:03 <zhipeng> please use the #info command when making a point :)
13:09:10 <joehuang> #info I found saggi has comment on my comment. The first one is the VM status. API interception and status cache is a good idea. How long for the cache time.
13:10:00 <saggi> joehuang: Depends on what is happening. gampel suggested we should also invalidate cache on certain commands.
13:10:10 <saggi> like when VM creation ends invalidate the cache
13:10:26 <joehuang> #info And one question for the cache is , if multiple VM be queried at the same time, can we fresh the status cache one by one or with one query api to cascaded Nova
13:11:00 <saggi> IMHO cache refresh should always be done in the background.
13:11:16 <saggi> Even if we invoked a refresh we should return stale data until we have an update or time out
13:11:36 <saggi> in the case of timeout we should update status to something the makes it clear to the use that the status is unknown
13:11:41 <joehuang> so there is one periodic polling task at the background to sync status
13:11:51 <gampel> we will pass runtime queries to the cascading service as saggi said and maybe we could have few refresh options on trigger periodic etc
13:11:52 <saggi> joehuang: yes
13:12:11 <saggi> joehuang: Should be configurable through the cascade API
13:12:34 <saggi> Since it's site related
13:12:49 <joehuang> Could be
13:13:17 <irenab> saggi: what is the data model managed by CascadingService?
13:13:36 <saggi> I don't understand the question :)
13:13:49 <saggi> what entities does it manage?
13:14:03 <gampel> we are in th process  of defining the DB for the cascaded layer
13:14:21 <irenab> Do you mean cascading?
13:14:26 <gampel> it should have the entities mapping
13:14:32 <saggi> in general it should contain mapping data (global UUID to site UUIDs) and site related information.
13:14:44 <gampel> yes cascaded sorry the TOP layer
13:15:06 <irenab> ok. When ready, please add it tho the doc
13:15:20 <joehuang> the VM status polling should be carefully if some long lasting task is executing, for example, volume migration
13:15:38 <saggi> that is handled by the Task Exec
13:15:49 <irenab> and what enitites will get UUID mappings
13:15:56 <saggi> it will poll in appropriate interval while a specific task is running.
13:16:12 <saggi> It's also true for starting a VM or creating a network.
13:16:37 <gampel> entities that we can not set their GUID on the bottom (cascaded) layer
13:16:57 <zhipeng> shall we just rephrase to top and bottom layer ?
13:17:03 <saggi> +1
13:17:04 <irenab> yes :-)
13:17:07 <zhipeng> it would be more easier to remember
13:17:08 <joehuang> If we keep state machine in the cascading layer, be sure the polling task will not harm the state machine in the task
13:17:12 <gampel> +1
13:17:25 <joehuang> +1
13:17:40 <zhipeng> #info rephrase cascading/cascaded to Top/Bottom
13:18:16 <irenab> gampel: I guess it will be most of the entities, since majority generate uuid during resource creation
13:18:42 <gampel> yes unfortunately
13:19:11 <joehuang> vm, volume, backup, snapshot, even flavor, network,subnet,port, router...
13:19:23 <saggi> yep
13:20:07 <gampel> Joe: you raised a requirement that is not supported in this design to be able to control the bottom from horizon  on local site
13:21:07 <irenab> gampel: why to restrict it?
13:21:10 <saggi> joehuang: Could you elaborate on the use cases.
13:21:26 <joehuang> yes. In OPNFV multisite project, the local APP manager need to be able to provision app even other sites failed
13:21:55 <gampel> But will he need to create resources ?
13:22:17 <joehuang> yes, create new VM.volume at least
13:22:37 <gampel> Not network ?
13:22:45 <saggi> joehuang: But what if he is missing the networks. Current configuration is reactive.
13:22:50 <joehuang> These two scenario can work independently, but not together
13:23:07 <saggi> What two scenarios?
13:23:10 <joehuang> Network too if needed
13:23:40 <gampel> network is a shared resource and this make it more difficult to sync to all sites
13:24:08 <joehuang> In the past, we often provide one scenario: multisite with one global API service which is provided by the top layer
13:25:02 <joehuang> This is what has been reflected in the design doc, all resource provision request comes from the top layer
13:25:19 <saggi> joehuang: Sow what comes from the bottom layer
13:25:25 <saggi> sow=so
13:25:55 <joehuang> On the other hand, another scenario, don't want the single top API layer
13:26:51 <joehuang> but still need the centralized service to provide cross neutron networking, image replication, security group replication, from one site to another site
13:27:05 <saggi> joehuang: Without the top layer all the algorithms need to be built as distributed.
13:27:13 <saggi> hmmm
13:27:15 <gampel> the problem will be to sync the change made in one site  horizontally to all other sites
13:28:02 <gampel> the current design was built with one TOP API in mind
13:28:24 <joehuang> to gampel: correct, the Nova/cinder/neutron API can still be called in each site seperatly
13:28:37 <saggi> joehuang: What about just making the Top layer as distributed. You could just install it on every site.
13:28:58 <joehuang> only if some cross OpenStack function, will issue api calling to the centralized service
13:29:13 <gampel> It's only possib
13:29:35 <joehuang> so I suggest to make the newly introduced service to work in these two scenario
13:29:38 <gampel> it is only reasonable  if we introduce some constraints on which resource creation is allowed
13:30:07 <saggi> joehuang: If we make the Top layer able to work on multiple sites. Using distributed database.
13:30:27 <gampel> As far as we understand, getting it accepted by the openstack community is topmost priority
13:30:29 <gampel> is this correct?
13:30:46 <joehuang> yes
13:30:57 <gampel> in that case, we will not be able to comply with what you're saying at the moment
13:31:09 <gampel> you need to understand that NFV and Openstack use cases are very different
13:31:14 <gampel> and in many cases collide
13:31:34 <gampel> the OPNFV community does not understand this and that is why they face a lot of problems when coming to openstack
13:31:52 <gampel> introducing changes into the underlying openstack will be rejected
13:32:00 <gampel> we need to take a step back here
13:32:02 <gampel> c
13:32:15 <gampel> clearly define the requirements and then think clearly what can be done
13:32:22 <gampel> we do not design on irc
13:32:24 <joehuang> for sure. no change to the underlyingOpenStck
13:32:46 <gampel> you cannot keep the underlying openstack unchanged and yet sync changes back to the top
13:33:33 <irenab> maybe more advanced case, can be get bottom resources and allow to match them top one
13:33:52 <saggi> We don't want bottom being aware of TOP
13:33:58 <gampel> I suggest we just focus on the different use cases now, list the requirements and then see how to resolve the conflicts between openstack cloud and NFV
13:34:03 <joehuang> the second scenario does not introduce change to the bottom openstack
13:34:21 <irenab> saggi: agree, thas why top will retrive the bottom, and user will match
13:34:47 <joehuang> absolutely "We don't want bottom being aware of TOP"
13:35:20 <irenab> I think it makes sense to add functional requirements section in the doc. It starts directly with design principles.
13:35:44 <irenab> So maybe few user stories will clarify the scope
13:35:50 <gampel> that will be very hard to sync by pool mode , i think that we should limit the resource creation
13:35:58 <gampel> irenab: i agree
13:36:14 <joehuang> make sense to describe the requirement in the doc
13:36:31 <zhipeng> I agree that certain constraints should be placed
13:36:36 <joehuang> what is "limit the resource creation"
13:36:39 <gampel> OK i can add you both as author
13:36:49 <saggi> I also wouldn't like the user to directly access the bottom if it's being managed.
13:37:11 <zhipeng> not all scenarios of creation should necessarily be needed in Tricircle
13:37:13 <zhipeng> joehuang
13:37:38 <joehuang> Ok, I will also describe the second scenario in more detail
13:37:38 <gampel> if we do not allow net create on the bottom layer just start stop create vm
13:38:04 <saggi> if it's managed we want to have full control or it will be hard to make sense of a host's state on error flows
13:39:01 <gampel> maybe we could split the work
13:39:15 <gampel> on the design
13:39:55 <joehuang> we can limit the content in the first stage, and make it work ASAP
13:39:55 <gampel> we need use cases , requirements , and architect design
13:40:04 <saggi> I would like to have the use cases written up
13:40:09 <saggi> gampel: +1
13:40:18 <zhipeng> +1 good idea
13:40:34 <joehuang> +1
13:41:11 <gampel> saggi and myself can go deeper on the POC and     design building blocks
13:41:48 <zhipeng> I would participate in the use case and requirements
13:42:23 <zhiyuan> me, too. use case and requirements
13:43:03 <gampel> joehuang: i think that you are the most  knowledge   on the use cases
13:43:03 <zhipeng> we could use your observations as well irenab
13:43:13 <joehuang> ok, I'll also working on use case/ requirements/design part. The doc is already a good base for design
13:43:44 <gampel> I will add you so you could edit the document
13:44:15 <joehuang> Can we co-work on the google doc just like etherpad?
13:44:20 <gampel> yes
13:44:46 <zhipeng> google doc is etherpad on steroid
13:44:55 <gampel> another topic is the l2-gw
13:45:34 <gampel> we started looking at the API for the networking-l2gw and it need to be modified a bit
13:45:42 <joehuang> Good. I think the major challenge is that we need to support the second scenario or not , or step by step
13:46:05 <joehuang> L2GW currently is for Neutron inside to outside
13:46:22 <joehuang> but not for cross -neutron
13:46:39 <gampel> it currently focused on another use case connect to HW
13:46:50 <zhipeng> #agreed work split on design doc drafting, gampel and saggi on designing blocks, zhiyuan and zhipeng on use case/req, and joe on overall enhancement
13:46:52 <joehuang> Agree
13:47:25 <saggi> +1
13:47:36 <gampel> agree we need to split the req to openstack and Opnfv
13:47:38 <zhiyuan> +1
13:47:39 <gampel> +1
13:48:02 <zhipeng> #agreed seperate req in opnfv from openstack
13:48:10 <joehuang> We need enhancement on the L2GW api, but L2GW api itself is not merged into the trunk yet
13:48:30 <zhipeng> that was supposed to be networking-tricircle right?
13:49:00 <joehuang> +1
13:49:44 <zhipeng> gampel joehuang, Kyle just post new admin rules for networking-* repos, dun know if we would be affected
13:50:02 <zhipeng> should be nothing but tagging
13:50:27 <zhipeng> we should check it out to make sure tho
13:50:54 <gampel> we want to use networking-l2gw but i am not sure if they will agree to support site to site tunnel creation we will try to start talking with them
13:51:35 <joehuang> that's important to have site 2 site suport on L2GW
13:52:01 <joehuang> To zhipeng, what's the new rule
13:52:44 <zhipeng> joehuang not rule per se, check it out in the mailing list
13:53:04 <joehuang> ok'
13:55:30 <joehuang> so let's continue work on the doc and have discussion in M-L?
13:56:25 <saggi> sure
13:56:28 <gampel> OK i it will be great to discuss offline  your idea for local site control
13:57:15 <zhipeng> we should always use ml as frequent as possible
13:57:23 <joehuang> yes. maybe I did not describe it very clear. in fact, the centralized service should have no function overlapping with each site.
13:57:38 <joehuang> agree
13:57:53 <gampel> Ok lets discuss it in the ml
13:58:21 <joehuang> thanks, see you
13:58:34 <gampel> thank you all bye
13:58:41 <saggi> bye
13:58:46 <joehuang> bye
13:58:46 <zhipeng> thanks bye
13:58:53 <zhipeng> #endmeeting