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