13:04:14 <zhipeng> #startmeeting Tricircle Weekly Meeting 2015.06.24
13:04:15 <openstack> Meeting started Wed Jun 24 13:04:14 2015 UTC and is due to finish in 60 minutes.  The chair is zhipeng. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:04:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:04:18 <openstack> The meeting name has been set to 'tricircle_weekly_meeting_2015_06_24'
13:04:33 <zhipeng> #topic Roll Call
13:04:39 <zhipeng> #info zhipeng
13:04:48 <joehuang> #info joehuang
13:05:20 <gampel> #info gampel
13:05:31 <saggi> #info smizrahi
13:05:56 <gsagie> #info gsagie
13:06:07 <joehuang> #info zhiyuan_cai
13:06:46 <zhipeng> ok nice to see you guys :)
13:06:52 <zhipeng> #topic agenda bashing
13:07:16 <zhipeng> #link https://wiki.openstack.org/wiki/Meetings/Tricircle
13:07:32 <zhipeng> #info today's agenda is on the meeting wiki page
13:07:47 <zhipeng> #info any suggestion on more items ?
13:07:56 <joehuang> ok for me
13:08:32 <zhipeng> ok
13:08:36 <zhipeng> anyone else?
13:08:44 <zhiyuan> fine for me, too
13:09:05 <zhipeng> #agreed agenda agreed
13:09:21 <zhipeng> #topic introduction of tricircle project
13:09:36 <gampel> maybe we could start discussing the clean code baseline for tricircle
13:09:45 <zhipeng> joehuang maybe you could briefly introduce a little bit?
13:09:59 <zhipeng> including the clean code base
13:10:13 <joehuang> # I'll introduce background for a file
13:10:30 <joehuang> #info The Tricircle idea is originated from two practical projects.
13:10:51 <joehuang> #info We have a multi-region solution delivered to our customer, the customer complained on some manual operation like has to configure the VPN connection for the router allocated in different OpenStack instances, and has to repeat that for a new tenant.
13:11:19 <joehuang> #info and also like security group, it is difficult to configure per region base for a tenant
13:12:35 <joehuang> #info and has to upload image to each region separatly, do the replication manually, but not on demand
13:12:55 <joehuang> #info and has to configure the tenant quota per region base. This is painful.
13:13:17 <joehuang> #info The second project asked us to provide a layer above multi-region OpenStack instances, but this layer must provide well adopted open api.
13:13:53 <joehuang> #info Some other customer also showed similar concerns, at last we think we need to find a way to solve these issues, that's the idea to start tricircle like project.
13:14:11 <joehuang> that's the background
13:14:46 <joehuang> Zhiyuan can introduce current code base, and then discuss the clean code base?
13:15:01 <zhipeng> sounds great to me
13:15:30 <zhiyuan> ok
13:15:47 <zhipeng> #info zhiyuan explains the clean code base
13:15:57 <zhiyuan> #info I have added a tag "poc" to the previous code and submitted the new code base.
13:16:38 <zhiyuan> #info The code base is simple enough that it only handles creating server and synchronizing status of server and ports, working with openstack 2015.1.0 version
13:17:07 <zhiyuan> #info We have built a third party CI to test the new code base. Thought currently this CI doesn't have voting right, we will manually guarantee test passes before patches can be merged.
13:17:36 <zhiyuan> that's all.
13:18:03 <zhipeng> gampel any questions?
13:18:08 <joehuang> Gampel's idea abot clean code base?
13:18:44 <gampel> do you have review system in place ?
13:19:30 <zhiyuan> yes, tricircle uses the official openstack review system
13:19:55 <zhiyuan> it is registered as a stackforge project
13:20:41 <gampel> Ok our Idea is to try and  clean code base with smaller footprint so in the cascading layer you do not have to run full OpenStack
13:20:48 <joehuang> Lauchpad is also ready?
13:21:32 <gampel> And to start with the Basic functionality
13:21:35 <saggi> Also we want the clean solution to integrate more cleanly with the existing openstuck code.
13:21:54 <saggi> meaning we want to use established pluggable points in the codebase.
13:22:26 <gampel> so if we deep dive into neutron
13:22:48 <joehuang> good idea
13:23:14 <gampel> we want to create networking-cacading that  implement ML2 mechnizem driver and L3 service plugin only
13:23:16 <joehuang> first to add a new ML2 mechanism driver for L2 functionality
13:23:37 <joehuang> similar idea
13:23:42 <gampel> yes
13:23:56 <zhipeng> #topic initial work goal setting
13:24:29 <zhipeng> so does it suffice to say, in L, our goal is to have ML2 pluggin work?
13:24:45 <zhipeng> networking-tricircle
13:24:46 <gampel> But we think that we do not need to save the port status in the cascading db we can pass it to the actual Cascaded OS
13:24:51 <joehuang> ML2 MD + L3 service plugin
13:25:19 <gampel> yes exactly
13:25:20 <joehuang> If we can reduce to store port status, it would be very helpful
13:25:42 <zhipeng> #info ML2 MD + L3 service plugin -> networking-tricircle, would be the L release goal
13:25:44 <joehuang> your idea to reduce the port status persistence?
13:26:16 <gampel> yes inorder to make the cascading layer simpler
13:27:00 <gampel> saggi is looking into Nova and what is the best place to plug our code
13:27:29 <zhipeng> gampel I sent out an email weeks ago asking about big tent in Nova and Cinder
13:27:41 <zhipeng> theiry replied that they are not there yet
13:27:41 <zhiyuan> so when a query about port comes to the cascading layer, it will pass this query to cascaded layer to retrieve the result?
13:27:50 <zhipeng> only Neutron now got big tent mode working
13:27:53 <joehuang> when we can discuss the idea for nova code plugin
13:27:58 <gampel> I am not sure we will make it for the L release
13:28:20 <zhipeng> so let's focus on Neutron for L release
13:28:54 <joehuang> and some basic functionality in nova
13:29:02 <zhipeng> if we got time
13:29:05 <gampel> saggi can  you please present what you learned about Nova
13:29:34 <saggi> I think it's possible to inject ourselves at the API layer
13:29:45 <joehuang> interesting
13:29:49 <saggi> I'm now testing implementing my own API classes similar to how cells is integrated
13:30:21 <joehuang> inherited from API class, but replace the implementation?
13:30:41 <joehuang> yes, there is a configuration to do that
13:30:41 <saggi> not inherit, reimplement
13:30:52 <saggi> like cells do
13:31:01 <saggi> you reuse the DB logic etc
13:31:09 <joehuang> the data will be persisted in the cascading layer or not?
13:31:22 <gampel> what we want to reuse is the API DB data module
13:31:31 <gampel> for all the openstack services
13:31:54 <joehuang> OK, if no data persisted, then quota control, flavor, etc, will be a problem
13:31:56 <saggi> As I see it, it will pass the calls to a cascaded layer that will keep mapping between the global UUIDS and local uuids
13:32:26 <joehuang> cool, the most headache issue is the uuid maping
13:32:29 <saggi> so the API class would reuse the DB calls but pass scheduling logic and such to the cascading layer
13:32:38 <zhipeng> saggi gampel could you guys generate a simple document about your method?
13:32:51 <zhipeng> google doc -ish :P
13:33:02 <saggi> joehuang: You will have to keep that mapping anyway you look at it
13:33:12 <gampel> yes we will and share it we want to intruduce a cascading service running in top opensatck
13:33:14 <joehuang> for others to easy to jump in
13:33:35 <saggi> joehuang: We want to keep the interface of the cascaded layer as close to the API layer as possible. Since this is the level that the casceding logic works at
13:33:42 <gampel> Ok we curently evaluating the solution
13:34:07 <zhipeng> ok so let's discuss with a specific document
13:34:24 <zhipeng> and gampel saggi please also take a look at the new tricircle wiki
13:34:25 <joehuang> is it possible to elinminate uuid mapping?
13:34:36 <zhipeng> so that we don't have architectural conflicts
13:34:46 <gampel> I do not think so
13:35:00 <gampel> Ok we will
13:35:08 <zhipeng> many thx :)
13:35:16 <saggi> joehuang: I wouldn't recommends it for network since you want to be able to distinguish between the same router on different sites
13:35:18 <joehuang> "I do not think so" what
13:35:33 <saggi> singleton entities like VMs could use the same GUID though for simplicity
13:36:10 <joehuang> yes, in neutron, one object will be mapped to multiple objects, for example  router
13:36:15 <zhipeng> #action gampel saggi specific design doc on API layer idea
13:36:26 <gampel> OK
13:36:34 <saggi> You will end up having to cross reference logs at some point and you don't want to have the same ID multiple times.
13:37:17 <joehuang> for singleton object, using one uuid is valuable for metering data, maintainnce
13:37:33 <joehuang> and billing, backup
13:37:46 <gampel> are you talking for the VM s GUID
13:38:30 <joehuang> for VM/volume/backup/snapshot, it's good to have only one uuid, no mapping is very great
13:38:45 <saggi> joehuang: As longs as you can cross refenrece GUIDs you can meter them.
13:38:50 <gampel> I am not sure it is posible migration  could be a problem
13:39:14 <saggi> joehuang: Storage is a whole different deal. We need to see how the vanilla replication works wrt IDs
13:39:52 <joehuang> ok
13:40:31 <zhipeng> #topic Project Logistics Discussion
13:40:45 <zhipeng> okey so we have CR ready
13:40:51 <saggi> joehuang: As long as you keep mapping between local and global IDs you should be able to cross reference everything.
13:41:02 <zhipeng> should we have BP+spec as most project does
13:41:07 <zhipeng> or just BPs
13:41:55 <saggi> zhipeng: I think it's too early in the projects life-cycle for that much bureaucracy. We still don't have a grasp on the general clean code design.
13:42:07 <gampel> I agree
13:42:09 <joehuang> cross reference, some times is difficult, for example, alarm will created on the GUID, but it generated inside the cascaded OpenStack
13:42:39 <saggi> joehuang: In that case it should be unique across all sites anway
13:43:12 <joehuang> to saggi, I need your detail idea about the cross reference GUID and uuid
13:43:16 <zhipeng> so let's table this, at least for L release
13:43:42 <zhipeng> about BPs/Specs I mean
13:44:16 <zhipeng> we will devote much of time in Neutron anyways :P
13:44:18 <saggi> joehuang: gampel will put it as part of the whole design suggestion doc we spoke about earlier
13:44:18 <gampel> OK i think BP is ok and spec is optional in this point
13:44:31 <zhipeng> gampel I agree
13:44:40 <gampel> some operational request/questions, where do you want us to place the new evaluation of the concept code
13:44:53 <joehuang> so the idea could be regiested as BP
13:45:34 <gampel> Ok we will register it as BP and add a link to online document
13:45:41 <joehuang> saggi:ok, we can discuss on that doc :)
13:46:05 <zhipeng> #agreed BP, no spec required for contribution
13:46:25 <zhipeng> another thing is that do we need an initial core reviewer team now?
13:46:25 <joehuang> shall we have a branch for concept?
13:46:38 <zhipeng> for example I think gampel and joehuang could be
13:46:55 <zhipeng> u 2 should be enough
13:47:01 <saggi> agreed
13:47:04 <zhipeng> to oversee BPs
13:47:06 <gampel> OK
13:47:12 <joehuang> ok
13:47:29 <joehuang> saggi and zhiyuan?
13:47:33 <zhipeng> #agreed joehuang and gampel serve as core reviewers
13:47:44 <joehuang> ok
13:48:02 <zhipeng> #topic AoB
13:48:10 <zhipeng> any other business :)
13:48:29 <joehuang> to gampel: shall we have a branch for concept code
13:48:36 <gampel> were do we develope the valuation of the concept code in the master
13:48:40 <joehuang> or a new folder
13:48:51 <gampel> under another directory or diffrent branch
13:49:28 <joehuang> in the master is also good for me. We need to fail fast at the early stage
13:49:42 <zhipeng> agree on master
13:49:47 <gampel> Ok
13:49:59 <zhiyuan> so do I need to turn off the current CI test job? Since it would not fit the concept of code
13:50:42 <joehuang> it would ok, but need to improve if new code merged
13:50:56 <gampel> saggi what do you think
13:51:33 <saggi> gampel: I tend towards the branch option
13:51:51 <saggi> That is what branches are for, testing new ideas
13:52:00 <saggi> you can merge later
13:52:10 <saggi> or abandon
13:52:24 <gampel> so we develop in the branch and then if it is viable we restructure the master
13:52:37 <saggi> if it's doesn't work. An the original code is uneffected
13:53:00 <gampel> Ok fine with me
13:53:02 <joehuang> this may be better, to keep the master always working
13:53:13 <joehuang> me too
13:53:20 <gampel> i agree
13:53:36 <zhipeng> #agreed concept of code in a branch
13:54:02 <joehuang> can zhiyuan add a new branch for concept code?
13:55:07 <zhipeng> joehuang we have an irc channel for tricircle right?
13:55:15 <zhipeng> #openstack-tricircle?
13:55:21 <joehuang> yes
13:55:45 <zhiyuan> +1
13:55:45 <zhiyuan> ok, what name do you prefer?
13:55:47 <zhipeng> #info for daily discussion other than weekly meeting, we could use #openstack-tricircle
13:56:38 <gampel> ok thx, the name does not matter
13:56:40 <joehuang> concept? or idea?
13:56:55 <saggi> joehuang: for the branch?
13:57:10 <joehuang> yes, for the branch
13:58:07 <saggi> joehuang: that's a tough question :)
13:58:47 <joehuang> we can do it tomorrow, it's 10:00pm here :)
13:58:59 <saggi> joehuang: OK, good night
13:59:01 <zhiyuan> and joe, maybe you clean the core member team to just keep you and gampel? there are too many core members currently...
13:59:22 <joehuang> ok, will do
13:59:32 <zhiyuan> thx
13:59:33 <zhipeng> #action joehuang to clean core member team
13:59:43 <zhipeng> ok thank you guys, very good meeting
13:59:49 <zhipeng> let's wrap it up today
13:59:56 <gampel> Ok good night
13:59:58 <zhipeng> and keep discussion going via emails
14:00:09 <zhipeng> good nite
14:00:10 <joehuang> thanks all
14:00:14 <zhipeng> #endmeeting