13:00:24 <zhipeng> #startmeeting tricircle
13:00:25 <openstack> Meeting started Wed Aug  5 13:00:24 2015 UTC and is due to finish in 60 minutes.  The chair is zhipeng. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:29 <openstack> The meeting name has been set to 'tricircle'
13:00:37 <joehuang> hi
13:00:38 <zhipeng> #topic Roll Call
13:00:44 <zhipeng> hello everyone
13:00:51 <zhipeng> #info zhipeng
13:00:53 <gampel> #info gampel
13:00:54 <joehuang> #info joehuang
13:01:04 <saggi> #info saggi
13:01:12 <zhiyuan> #info zhiyuan
13:01:38 <zhipeng> :)
13:01:58 <zhipeng> #topic Action Item Review
13:02:24 <joehuang> #info Keystone part has been updated into the google doc
13:02:45 <zhipeng> joehuang could you provide the link again?
13:03:14 <joehuang> #link https://docs.google.com/document/d/19BXf0RhkH8wEEymE2eHHqoDZ67gnzgvpr3atk4qwdGs/edit#heading=h.5r6zgqbiehsh
13:03:25 <gampel> it is link in the launchpad blueprint "new-design"
13:03:29 <joehuang> #info keystone federation has not been tried yet
13:04:09 <irenab> #info irenab
13:04:13 <joehuang> #info keystone federation should have a lower priority in our development
13:04:26 <zhipeng> welcome irenab :)
13:04:33 <irenab> hey :-)
13:04:44 <joehuang> hi
13:04:54 <gampel> hi irenab
13:05:10 <zhiyuan> hi
13:05:29 <joehuang> hi zhipeng
13:05:49 <joehuang> could you list the AI in last meeting
13:06:18 <zhipeng> update the doc for how to work with KeyStone, joehuang gampel check what mistral supports and which taskflow we want in the reference implementation discuss pluggable cascade service module on bottom
13:06:43 <joehuang> to use mistral or not
13:07:04 <zhipeng> gampel have you checked that out ?
13:07:09 <gampel> Mistral  support response
13:07:11 <joehuang> and pluggable bottom cascade service
13:07:32 <zhipeng> let's take care of taskflow first :)
13:07:47 <joehuang> if a bootvm task is assigned to mistral
13:08:11 <gampel> So I think that the best will be to create a pluggable flow  compiler + taskflow
13:08:14 <joehuang> can we get the regarding port/volume information from the response
13:08:31 <gampel> Yes
13:08:56 <gampel> we can define what we response in the task flow definition
13:09:04 <zhipeng> #info gampel think that the best will be to create a pluggable flow  compiler + taskflow
13:10:40 <gampel> For the first implementation reference we could use Mistral or to reuse the POC implementation
13:11:29 <gampel> Joe can you please describe the POC taskflow execution and if it is possible to integrate it
13:12:05 <joehuang> I am still afraid the risk in using mistral for some task, but I  can not be sure which one will be risk
13:12:55 <joehuang> in PoC, no task flow used, just code the logic
13:13:02 <gampel> we could start with a reference implementation using built in neutron -nova clients
13:13:10 <saggi> joehuang: We are working closely we minstral developers so they could add thing that are missing
13:13:42 <saggi> joehuang: Also, having the Task Compiler and Task Executor pluggable will allow us to have alternative implementations as well
13:14:11 <gampel> in order to make the  development process simple, we need to first create the pluggable module
13:14:12 <joehuang> for example, bootvm will have to check image, create volume, create port, if possible, replicate image required
13:14:39 <joehuang> agree. we can use plugin in the taskflow
13:15:01 <joehuang> so that different implemention is possible
13:15:02 <gampel> this is no problem with mistral but we could start with a reference plugging that use built in clients
13:15:33 <joehuang> ok, use built-in client first
13:16:08 <zhipeng> #info start with a reference plugging that use built in clients
13:16:23 <zhiyuan> sorry, built-in client here means client in Mistral?
13:17:01 <joehuang> pythonclient for nova/ciner/neutron?
13:17:08 <gampel> no i mean the same as you used in the POC build in library for nova/neutron
13:17:21 <zhipeng> should be what joe suggested
13:17:26 <joehuang> ok
13:17:52 <zhiyuan> got it
13:18:29 <joehuang> so next topic, the bottom cascade service and status sync
13:19:25 <joehuang> ok. I remember some risk
13:19:34 <gampel> as we started discussing in last meeting we think that the status should be pushed by a bottom cascading service
13:19:38 <joehuang> recall, not remember
13:19:56 <joehuang> for IP address management in the cascading layer
13:20:26 <joehuang> so the IP address will be done in the neutron api server
13:20:45 <gampel> i am not sure i follow ?
13:21:15 <joehuang> and the allocaled ip address/mac should be used in calling the bottom neutron
13:21:53 <gampel> you are  talking about the inter cloud connectivity (l2GW)
13:22:27 <joehuang> no, just bootvm process
13:22:50 <joehuang> ok. I'll describe it in the mail-list, to see if we can use mistral in the process
13:23:49 <gampel> Ok i though we changed  the topic
13:23:59 <joehuang> ok
13:24:01 <saggi> joehuang: the bottom cascade service is supposed to address the need of having multi-site information at the bottom layer
13:24:14 <saggi> joehuang: We need that for the l2gw
13:24:27 <saggi> joehuang: We will probably need that for storage sync as well
13:24:50 <gampel> the idea is that it will provide 1) l2GW 2) notification 3) ...
13:24:52 <joehuang> L2GW  is an extention of neutron or seperated in the cascade service?
13:25:10 <zhipeng> part of the bottom service
13:25:21 <saggi> zhipeng: correct
13:25:26 <gampel> the  cascading service will implement the API if they are suitable
13:25:29 <joehuang> have you read the mail I sent in the m-l
13:26:07 <joehuang> how to notify the vm/volume/port status to the cascading service
13:26:13 <gampel> the l2GW implementation does not fit inter cloud connectivity it is for HW connection
13:26:44 <joehuang> yes. if's for overlay and underlay networking
13:26:56 <joehuang> not for cross neutron overlay networking
13:27:57 <joehuang> how to get and send the vm/volume/port status to the cascade service
13:28:14 <gampel> I started looking into if we could reuse the API extent what we are missing or do we need a completely different API for inter cloud connectivity
13:28:51 <gampel> it could be done in few ways the simplest  will be to call the cascading service API
13:29:45 <joehuang> how will the bottom cascade service get these status
13:30:25 <saggi> Sorry, clicked the X button by mistake :)
13:30:41 <joehuang> welcome back
13:30:58 <gampel> we will have a full design of the bottom in the document but the idea is that you have pluggable implementation for different Networking Plugins
13:32:31 <gampel> in order to subscribe to the changes
13:32:47 <joehuang> I think cross neutron L2 networking should be an extention of neutron. it may be different from current L2GW
13:32:56 <joehuang> how to subscribe
13:33:10 <joehuang> listen the message bus
13:33:28 <joehuang> some even of status change has not been sent yet
13:34:08 <gampel> I think that we should not focus on what we agree and define the next development steps and divide the work what is missing and leave the design to the mail list
13:35:26 <joehuang> but we need to think about what should be included in the cascade service, and is it feasible
13:36:52 <joehuang> introducing a new service in the bottom layer will change the the bottom openstack distribution deployment
13:36:52 <gampel> sure I agree, but what do you think is not feasible we can discuss this in the mail  list and focus here on the tasks we have and status
13:37:27 <saggi> That is why we are suggesting a single bottom cascade service to consolidate the changes
13:37:31 <saggi> at the bottom layer
13:38:15 <joehuang> it would be better if no touch in bottom layer
13:38:41 <joehuang> zhiyuan suggest have a job creator in the top cascade service
13:38:50 <saggi> joehuang: I agree, but there is no avoiding it for network connectivity
13:39:20 <joehuang> if we can have this extention in Neutron, then all distribution will include it
13:39:21 <gampel> you will need to add an local agent that do not modify all the other services in order to have some thing that could scale
13:39:21 <zhipeng> #action discuss bottom cascade service design in mailinglist
13:39:40 <gampel> I agree
13:39:46 <zhipeng> let's discuss this in detail in mailinglist
13:39:49 <zhipeng> :)
13:40:02 <joehuang> polling doen't mean not scaling.
13:40:10 <zhipeng> #topic patch work discussion
13:40:14 <joehuang> ok
13:40:30 <zhipeng> zhiyuan and saggi have been working several patches
13:40:43 <zhipeng> and joehuang gampel all comment on them
13:40:50 <zhipeng> anything we need to address here?
13:41:05 <joehuang> I am working on the cascade service rest api framework
13:41:11 <joehuang> and test framework
13:41:18 <zhipeng> dal, networking-tricircle
13:41:27 <zhipeng> joehuang would that be new BPs ?
13:41:47 <saggi> I got a comment that sent me back to the drawing board. I'm now placing the nova hook in the same layer as the cells management.
13:41:52 <joehuang> yes, new bp and under the new-design bp umbrella
13:42:34 <zhipeng> #info joehuang is working on the cascade service rest api and test framework
13:42:37 <joehuang> ok, place the hook in the nova API
13:42:59 <zhipeng> #info saggi now placing the nova hook in the same layer as the cells management
13:43:11 <gampel> we are missing in the DAL assess to the resources like get_network( .....) will return the net data from the Neutron and all the mapping data
13:43:13 <joehuang> and just to replace the nova-api RPC call to conductor and compute
13:43:39 <saggi> joehuang: exactly
13:44:01 <saggi> joehuang: It is less of a clean cut than I hoped it would be though
13:44:35 <saggi> joehuang: I still need to duplicate a lot of the code. But cells seems to duplicate it as well so I guess it's as intended.
13:44:58 <joehuang> access the data for get_network is a rpc to call neutron api, then to neutron dal
13:45:16 <joehuang> or directly call neutron dal
13:45:23 <gampel> i think it should use neutron API
13:45:58 <gampel> I think that the DAL should use the neutron API in the context of the caller
13:46:15 <zhipeng> zhiyuan any suggestion from your side ?
13:46:20 <saggi> It should use the neturon API. We don't want to depend on the DB schema, it changes to frequently and is not supported
13:46:26 <gampel> to the TOP neutron
13:46:49 <joehuang> will it produce some loopback?
13:47:13 <gampel> i do not think it will we will only can info request ?
13:47:25 <gampel> not actions and we forward only actions
13:47:53 <zhiyuan> so dal provides api to access top layer resources?
13:48:03 <saggi> and internal DB
13:48:18 <saggi> it collects the needed information from all data sources
13:48:22 <joehuang> some issue here
13:48:57 <gampel> what issue ?
13:49:06 <joehuang> for tenant user, some network / port information can't be retrieved through tenant information
13:49:28 <joehuang> for example, provider network informantion, vlan segmentation id
13:49:44 <joehuang> and port information like port binding
13:49:52 <gampel> why do you need the segmentation id in the DAL
13:50:13 <joehuang> because api layer will filter some fields to the client
13:51:46 <gampel> we need the DAL in order to reconstruct the missing resources, I am not sure i understand which resource info we are missing
13:51:47 <joehuang> segmention id is not required if we do not want have same segmentation id and provider network type between the top layer and the bottom layer
13:52:30 <saggi> We can't control the segmentation ID in the bottom layer
13:52:32 <gampel> using the provider API to set the segmentation ID is not a very good approach in my opinion
13:53:11 <gampel> you must use admin context and it will not work with all implementation some do not have segmentation id
13:53:13 <joehuang> so we will only provide vxlan network in the top layer?
13:53:56 <joehuang> if we only use vxlan network, it'll be ok. no need for segmentation id mapping
13:54:24 <joehuang> and some port fileds will be only visible to admin context
13:55:00 <gampel> for the TOP layer it does not really matter vxlan or not
13:55:45 <gampel> are there other resource info that we could not get using the tenant context     ?
13:58:01 <zhiyuan> :gampel do you have a list of resources that need to be retrieved so we can check if it can be done by tenant context?
13:58:32 <joehuang> yes, one by one
13:58:54 <gampel> this is the  design work we started doing on the resource mapping in the document
13:59:33 <zhipeng> so let's fill those in the document, and see if anything is missing or redundant
13:59:35 <gampel> we have an image with tree represent the Nova-Neutron resource and their dependencies
14:00:43 <zhipeng> #action gampel to have a list of resources that need to be retrieved so we can check if it can be done by tenant context in the design work on resource mapping
14:00:55 <joehuang> the external network and IP/ port management ?
14:00:58 <gampel> Ok i think that the next task on the DAL should be base template for one resource (lets say network)
14:01:02 <zhipeng> would this be ok? :)
14:01:13 <joehuang> floating ip
14:01:51 <joehuang> network/router is tenant level concept
14:02:07 <gampel> then we can easily add all the rest it should  read the net data for neutron and the net mapping form the local DB
14:02:15 <joehuang> but for external network / floating ip belongs to admin context
14:02:43 <zhipeng> ok let's discuss this via design doc
14:02:51 <joehuang> seg also tenant level resource
14:03:00 <zhipeng> time is running up :)
14:03:25 <joehuang> thanks
14:03:46 <zhipeng> thanks guys, great session today
14:03:51 <zhipeng> #endmeeting