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