07:06:36 <joehuang> #startmeeting multisite
07:06:36 <collabot> Meeting started Thu Sep  1 07:06:36 2016 UTC.  The chair is joehuang. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:06:36 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
07:06:36 <collabot> The meeting name has been set to 'multisite'
07:06:40 <joehuang> it's ok
07:07:06 <joehuang> let's discuss next step for multisite, it's open discussion, any idea could be
07:07:11 <SAshish> CLI
07:08:07 <sorantis> #info dimitri
07:08:12 <SAshish> #info Ashish
07:08:16 <joehuang> #info joehuang
07:08:30 <sorantis> Kb CLI
07:08:34 <sorantis> resource sync
07:08:45 <joehuang> would like to know your thoughts for the next step
07:08:51 <sorantis> I would also like to revisit the geo-red use casea
07:09:13 <joehuang> for CLI, including SDK
07:09:27 <SAshish> first with just the CLI
07:09:30 <SAshish> then openstack sdk
07:09:38 <sorantis> we have some bugs and bps in the pipe
07:09:46 <joehuang> what's the geo-red
07:09:52 <sorantis> +1 SDK is not a priority for now
07:09:58 <sorantis> geographical redundancy
07:10:29 <joehuang> ok, good, let's visit geographical redundancy
07:11:05 <joehuang> for resource sync, what's will be in the list
07:11:42 <sorantis> as a start I’m thinking, security groups, ssh keys
07:12:02 <sorantis> later images, and image metadata
07:12:32 <joehuang> ssh_keys could be first, for security groups, it's quite different, we have tried that in Tricircle
07:12:43 <sorantis> and what happened?
07:12:58 <SAshish> it is just the db entry right?
07:13:02 <joehuang> the challenge is in the remote group
07:13:16 <joehuang> no, it's more than db entry
07:13:18 <sorantis> can you elaborate?
07:13:20 <SAshish> okay
07:13:36 <joehuang> one second to type
07:13:59 <joehuang> in SEG, remote group is allowed in the rule
07:14:44 <joehuang> and for the ports which use the security group will be applied with the rule
07:15:23 <joehuang> so neutron will lookup all ports which use the SEG id
07:15:32 <joehuang> for cross neutron cases
07:15:47 <joehuang> in the remote neutron, you don't have these ports resources
07:16:33 <joehuang> if the remote group includes ports in another neutron, then issue will be there
07:16:43 <sorantis> what if we don’t sync the sec groups with that kind of rules
07:16:53 <joehuang> unless you populate all these ports from remote neutron to local neutron
07:17:13 <joehuang> Dimitri, you are smart guys!
07:17:17 <joehuang> Dimitri, you are smart guy!
07:17:54 <joehuang> In fact, the remote group mainly used for default SEG, and which is the tradidtion from AMAZON
07:18:01 <sorantis> We may encounter a similar issue with flavors, in case a flavor will have extra_specs. there’s not guarantee that it will instantiate in a different VIM
07:18:49 <joehuang> we can disucss one by one, consider you have only 10 minutes left
07:19:02 <sorantis> ok
07:19:07 <joehuang> we can list topics to be discussed and work next step
07:19:56 <joehuang> And in Tricircle, we divide tricircle into two project, one dedicated for networking autoamation working under multi-region mode
07:20:17 <joehuang> so cross Neutron networking automation could be one topic
07:20:24 <joehuang> even can help gluon
07:20:34 <joehuang> now gluon lives under neutron
07:21:09 <sorantis> isn’t the cross neutron automation handled by the SDN?
07:21:25 <joehuang> for cross neutron networking automation, you can refer to https://docs.google.com/presentation/d/1kpVo5rsL6p_rq9TvkuczjommJSsisDiKJiurbhaQg7E/edit#slide=id.g165c607cf9_0_22
07:22:02 <joehuang> to Dimitri, some issues can't be addressed by SDN controller
07:22:45 <joehuang> we discussed in the opnfv mail-list for cross site gluon, and Bin admit there are somthing they not considered
07:23:31 <joehuang> the issues are global VxLAN segment management, IP/mac pool and allocation to avoid conflict
07:24:27 <sorantis> and SDN cannot handle it? I thought that SDN controller handles the global IP pool. And neutrons connect to it using corresponding plugins
07:25:04 <joehuang> ok, we can discuss that how to achieve that
07:25:57 <joehuang> the topics to be discussed
07:26:12 <joehuang> #info 1)KB CLI
07:26:21 <joehuang> #info 2)KB SDK
07:26:37 <joehuang> #info 3)Resources Sync
07:27:36 <joehuang> #info 3.1)SEG
07:27:54 <joehuang> #info 3.2)FLAVOR
07:28:08 <joehuang> #info 3.3)SSH KEY
07:28:31 <joehuang> #info 4)cross neutron networking automation
07:28:48 <joehuang> Is there other topics missed?
07:30:22 <sorantis> yes
07:30:43 <sorantis> we need to discuss also automated multisite deployment
07:30:59 <sorantis> since we’re already using Fuel, we can start cooperation with the Fuel project
07:31:14 <sorantis> currently we’re relying on the static deployment
07:32:05 <joehuang> 5) instllation cooperation
07:32:18 <joehuang> #info 5) installation cooperation
07:32:27 <sorantis> And also, as the follow-up, Kingbird installer should be a puppet module
07:32:57 <sorantis> I really have to run now, guys :( so sorry
07:32:57 <SAshish> so it will be as a plugin for MOS
07:33:13 <joehuang> but I think as a requirement project, we may put more focus on requirement and feature implementation
07:33:15 <sorantis> MOS plugin could be at a later stage
07:33:39 <sorantis> yes, but since we’re the ones developing kingbird, the requirement is back to us
07:34:52 <joehuang> we can work together with other teams to do the integration, it'll eat our all time if we put more focus on the installation integration
07:35:17 <sorantis> that’s why we need to cooperate with Fuel guys
07:36:13 <sorantis> ok, getting late
07:36:18 <joehuang> yes, we can cooperate with these guys
07:36:22 <sorantis> thanks for bringing this up!
07:36:30 <joehuang> ok, contintue discuss next meeting
07:36:39 <joehuang> see you , have a good day
07:36:48 <sorantis> let’s continue offline and start the D-cycle backlog
07:36:52 <sorantis> you too
07:36:55 <joehuang> ok
07:37:00 <sorantis> bye!
07:37:06 <joehuang> bye
07:37:12 <joehuang> #endmeeting