13:01:55 <zhipeng> #startmeeting tricircle
13:01:56 <openstack> Meeting started Wed Aug 12 13:01:55 2015 UTC and is due to finish in 60 minutes.  The chair is zhipeng. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:02:00 <openstack> The meeting name has been set to 'tricircle'
13:02:09 <zhipeng> #topic Roll Call
13:02:15 <zhipeng> hi guys
13:02:30 <gampel> hi
13:02:32 <zhipeng> joehuang won't be able to join us today
13:02:33 <gampel> info gampel
13:02:42 <zhipeng> #info gampel
13:02:46 <zhipeng> #info zhipeng
13:02:51 <gampel> #info gampel
13:03:18 <zhipeng> let's wait 2 more minutes for more people to join :)
13:03:30 <saggi> #info smizrahi
13:05:00 <zhipeng> zhiyuan here ?
13:05:30 <zhipeng> #info zhiyuan
13:05:54 <zhiyuan> hi, zhipeng
13:06:05 <zhipeng> hey, was waiting for you :)
13:06:17 <zhipeng> #topic local/bottom cascade service
13:06:35 <zhipeng> #info zhiyuan and joe had some discussion on this on the mailinglist
13:06:47 <zhipeng> any further comments about this item ?
13:08:04 <gampel> I suggest we focus on the task and a separate meetings for design for each topics
13:08:40 <zhipeng> okey I was running through AIs in the last meeting :)
13:09:09 <zhipeng> which tasks would you suggest to focus on? gampel
13:09:46 <gampel> to focus on report what is teh status of each task and what are the next task so we are all in sync
13:10:33 <gampel> we could have design  meetings in #openstack-tricircle for each topic
13:11:33 <zhipeng> okey
13:11:52 <zhipeng> #topic task status sync
13:12:16 <gampel> saggi do you want to report the status of nova
13:12:22 <saggi> sure
13:13:04 <saggi> As you might remember I started working on integrating at the same place the cells API is integrated.
13:13:16 <saggi> But this is no sustainable as the hook point is going away
13:13:36 <saggi> in the latest summit they decided on removing the cells API and integrating it into the regular nova API.
13:13:47 <saggi> Instead I thought of a different idea
13:14:10 <saggi> I implemented the scheduler API inside the cascade service
13:14:39 <saggi> And directly access the conductor from the cascade service to create fake compute nodes
13:14:46 <saggi> currently they are not backed up by anythiong
13:15:05 <saggi> but the idea is to have each fake compute node backed up by a site
13:15:29 <saggi> all fake compute nodes have the same address (the cascade service) but have different names.
13:15:48 <saggi> When nova starts a VM it will use the scheduler to decide where to schedule it
13:16:18 <saggi> since the cascade service is the scheduler we can select the proper compute node (site)
13:16:49 <saggi> then it will send the build_instance() command with the proper nodename to the cascade service which will then know what site to allocate the VM
13:16:58 <saggi> since the nodename would identify the site
13:17:23 <saggi> that way we use only supported pluggable interfaces in the nova side.
13:17:30 <saggi> And have 0 LOC changes in core nova
13:17:49 <saggi> I would like to get feedback about the idea
13:18:19 <gampel> saggi did you mentioned that cell hook is going away next release
13:18:22 <zhipeng> so the scheduler API provided by the cascade service bypass the original nova schedular api
13:19:07 <saggi> yes, I disable n-sch and have the cascade service listen on the scheduler topic
13:19:47 <gampel> it is a way for  be  non intrusive on nova code saggi will update the design document once he get it all to work
13:20:20 <zhipeng> it sounds a great idea to me :)
13:20:32 <gampel> Zhiyuan is in the meeting ?
13:21:08 <zhiyuan> yes
13:21:27 <gampel> Your patch is approved do you want me to merge it ?
13:21:37 <gampel> do you wnat to report the status
13:21:58 <zhipeng> #info saggi suggest a way of having sch API in cascade service, and fake compute node as well so that cascade service serves as a enlarged Nova node, saggi will update the design doc once the coding functions
13:23:27 <zhiyuan> this week I spent most of the time on the CJK project so not much progress on the dal part
13:24:17 <zhipeng> zhiyuan do you want gample to merge the DB patch since he has +2 it?
13:24:24 <gampel> it seem that the basics DB is ready and the context
13:24:40 <saggi> doesn't it depend on some of my unmerged code?
13:24:44 <saggi> gampel: ^^
13:25:13 <gampel> yes i want to talk  about that patch, joe blocked it and he is not here
13:25:25 <zhiyuan> yeah, we need to merge saggi's patch first.
13:26:10 <gampel> I think that currently we should just cast the update_network
13:27:10 <gampel> And all the networking change are related to all the bottom open stack
13:28:11 <zhiyuan> when using cast, all the cascading services will receive that message. Is this a wanted behaviour?
13:28:17 <saggi> Only at the cascade service level we can figure out what bottom services to update. So it will have to be boardcast to all of them so they can decide whether to propagate it down.
13:29:05 <saggi> When network properties change we need to update all the bottom sites that have that network entity set up. Only the the cascad service layer knows about that
13:29:42 <gampel> I will try to discuss this with joe but I do not understand is objection to the merge
13:29:42 <saggi> The top thinks everything is set up everywhere.
13:29:59 <saggi> It can't decide on which cascade service to update.
13:30:06 <saggi> It needs to know about mapping
13:30:16 <saggi> Only the cascade service knows about the mapping.
13:30:56 <zhipeng> I think Joe thinks the top should be able to know which to update
13:31:04 <zhiyuan> one cascade service is responsible for all the bottom OpenStacks or only one  OpenStack?
13:31:27 <gampel> one or more
13:31:27 <saggi> The top can't know it's a layering violation.
13:31:33 <gampel> i agree
13:32:09 <gampel> and i think in this time we need to focus on having all the path ready from the top to bottom
13:32:19 <zhiyuan> I think joe's idea is that one cascade service can handle all the bottom OpenStack, so no need to fanout the message
13:32:55 <saggi> If there is only one than it doesn't matter what we use :)
13:33:51 <gampel> you need some one to sync the request to one bottom so the request will not get out of sync time wise
13:34:15 <gampel> i think that we should focus now on full path top to bottom comminication
13:34:46 <gampel> latter we can check which part is the bottle neck
13:35:37 <gampel> one assumption we have in the design is that the workflow is an external service and that is the biggest  load
13:36:54 <saggi> b
13:37:01 <gampel> I will discuss this with Joe tomorrow
13:38:51 <gampel> If it is OK i want to discuss the next task DAL, Dependency builder
13:38:57 <zhipeng> #action gampel further discuss with joe on saggi's patch
13:39:06 <zhipeng> go ahead
13:39:14 <zhiyuan> ok
13:39:30 <gampel> I know that joe is working on the API do you knwo the status
13:40:18 <zhiyuan> On last Friday joe finished most of the work. I think he can submit the code tomorrow.
13:40:49 <saggi> looking forward to it
13:41:20 <gampel> very good so the next task i think we have is the DAL communication with TOP North API and the Dependency builder
13:43:12 <zhiyuan> dal needs to expose API to query the resources information stored in the top layer, right?
13:43:39 <gampel> Yes
13:44:44 <gampel> and provide API to get resource data nad all the mapping data to the bottom opensatcks
13:46:04 <gampel> zhiyuan do you want to continue with the DAL
13:46:56 <zhiyuan> yes
13:47:33 <gampel> saggi when do you think you will be done with nova and what are your next planes
13:47:40 <zhiyuan> so DAL collect information via REST api?
13:47:50 <saggi> zhiyuan: yes
13:48:34 <zhiyuan> ok
13:48:50 <gampel> worst case and latter we detect some data that is not available from the the REST we use the mq i hope that we will not need to do it
13:48:52 <saggi> gampel: I'm I hope of getting the top only part set up soon. After that I'm blocked on DAL and WSGI for implementing the "Dependency Builder"
13:49:21 <saggi> Since I can't query dependencies without the DAL and can't set up bottom sites without the WSGI
13:49:27 <gampel> OK i can start looking into setting up mistral and compiling the tasks
13:50:45 <gampel> I think we need the flowing design Bottom service ( L2GW, notification ...)
13:51:12 <saggi> flowing design?
13:51:52 <gampel> yes meetings can we schedule  a time to discuss this in #opensatck-tricircle
13:52:37 <gampel> I know for most of you this time is very late at night we could do it earlier ?
13:53:04 <zhipeng> i think we could do one hour earlier ?
13:53:40 <gampel> when Monday  ?
13:54:02 <zhipeng> that would work for me :)
13:54:23 <zhipeng> let me send out an email to poll the time
13:54:33 <zhipeng> for our design meeting
13:54:34 <zhiyuan> Monday is fine
13:54:53 <gampel> Saggi is Monday good for you ?
13:55:58 <saggi> gampel: Yes, at least for the next few months
13:58:05 <zhipeng> gampel should we make this also a weekly thing or a one time thing just for next week?
13:58:35 <saggi> zhipeng: I think it should occur as long as there is something to discuss.
13:58:35 <gampel> I think maybe one/multiple  time per topic
13:58:51 <zhipeng> great
13:58:59 <gampel> i agree per design  topic
13:59:31 <zhiyuan> +1 per design topic
13:59:48 <zhipeng> #action announce design session next Monday
14:00:09 <zhipeng> btw I see irenab got several comments on the design doc
14:00:27 <zhipeng> we should address it sooner rather than later
14:00:32 <saggi> We also need to decide on what we are going to talk about before the meeting so that people have time to read up and prepare.
14:00:32 <gampel> Yes we will address them tomorrow
14:00:52 <gampel> I think lets start with the notification part
14:01:20 <ShillaSaebi> Hello all, we are about to start up the US docs team meeting momentarily
14:01:46 <zhipeng> sorry :)
14:01:51 <annegentle> heh we need a door to stand at and look in :)
14:01:51 <zhipeng> #endmeeting